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1.  Overview  of  NAVAIR  Portable  Source  Initiative  (NPSI) 


NPSI  is  a  simple  concept  with  a  simple  goal  to  minimize  the  redundancy  in 
database  production  across  platforms  without  inhibiting  innovation.  The  basic 
concept  of  NPSI  is  to  capture  value  added  work  performed  on  raw  source  data. 
This  concept  has  resulted  in  significant  cost  savings  and  increased  efficiency  of 
database  production  to  many  Department  of  Defense  (DoD)  programs  by 
minimizing  the  purchase  and  processing  of  new  source  data  required  for  future 
developments.  The  NPSI  archive  stores  refined  source  data  in  datasets  and 
makes  the  datasets  available  for  utilization  by  future  programs.  However,  unlike 
the  refined  source  data,  run-time  databases  are  not  stored  in  the  archive.  The 
visibility  of  data  assets  when  new  program  requirements  are  defined  and  the 
utilization  of  the  data  archived  by  NPSI  have  allowed  DoD  programs  to  vastly 
expand  their  training  gaming  areas.  NPSI  creates  new  opportunities  for  programs 
and  trainers  by  allowing  programs  to  do  more  for  less  and  sometimes  faster  than 
ever  before.  The  functional  diagram  of  the  NPSI  process  is  shown  in  Figure  1. 
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Figure  1  Functional  diagram  of  NPSI  process. 


1.1  Definition  of  Overloaded  Terms 

Synthetic  Environment:  The  synthetic  environment  is  the  overarching 
collection  of  databases  produced  to  provide  a  training  environment. 

Dataset:  A  dataset  is  a  collection  of  source  data  (e.g.,  imagery  data, 
elevation  data,  shape  files,  3-D  models,  etc.)  required  to  produce  a  database. 
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Database:  A  database  is  an  organized  collection  of  data  that  is  stored  and 
ready  to  be  read  by  another  system  typically  in  a  proprietary  format.  The 
database  is  derived  from  a  dataset. 

Run-time  database:  A  run-time  database  is  the  native,  often  proprietary, 
format  the  application  reads  to  produce  the  synthetic  environment.  While  not 
always  the  case,  the  run-time  database  is  often  considered  read-only. 

Raw  source  data:  Raw  source  data  is  data  that  has  not  been  processed  for 
use.  Raw  source  data  products  are  typically  acquired  by  a  third  party  vendor  and 
then  delivered  to  the  prime  contractor  or  to  the  prime  contractor's  supplier  to 
implement  many  of  the  corrections  listed  in  section  4.2. 

Refined  source  data:  Refined  source  data  is  data  that  has  been  processed 
and  corrected  for  use  within  specific  applications.  The  corrections  invested  into 
the  refined  source  data  have  significant  value.  By  reuse  of  the  refined  source 
data,  cost  savings  and  efficiency  can  be  achieved. 

1.2  NPSI  Concept  of  Operation 

The  mission  of  NPSI  is  to  provide  maximum  database  reuse  across 
Type/Model/Series  platforms  to  lower  the  life  cycle  cost  of  out-the-window  (OTW) 
visual  terrain,  3-D  models,  and  sensor  databases,  along  with  dataset  archive 
capability  and  short-notice  distribution  services.  The  functional  diagram  of  the 
NPSI  process  is  shown  in  Figure  1. 

1.3  Need  for  NPSI 

Databases  have  often  been  an  expensive  piece  of  training  systems. 
Oftentimes,  database  development  efforts  are  seen  as  a  mix  of  artwork  and 
engineering  design.  The  costs  of  these  databases  results  from  both  labor  hours 
needed  to  refine  data  and  from  materials  acquired  in  the  database  process. 
Unlike  simulator  hardware  and  software  costs,  which  have  decreased  in  the  past 
decade,  database  costs  have  been  stagnant.  The  greatest  opportunity  for 
optimization  and  cost  savings  in  database  designs  is  through  increased  efficiency 
and  reuse.  Without  reuse,  every  time  a  new  simulator  is  built,  a  new  database 
must  be  built  from  scratch.  A  need  for  reuse  can  be  shown  when  different 
programs  have  a  similar  database  requirement  in  the  same  geographical  area, 
but  are  separated  by  several  years.  In  the  past,  each  program  would  have 
created  a  custom  Camp  Pendleton  each  time  at  a  cost  of  hundreds  of  thousands 
of  dollars.  These  custom  Camp  Pendleton  databases  are  almost  exactly  alike.  In 
fact,  the  same  requirements  might  have  been  used  to  build  each  database.  The 
result  is  many  months  and  many  dollars  spent  to  create  each  one  individually.  If 
the  dataset  was  created  only  once  and  reused  to  create  each  follow-on  database, 
then  the  future  programs  would  have  saved  money  and  time  instead  of 
recreating  the  same  database.  In  order  to  meet  the  DoD  Directorate  5000.59 
(Under  Secretary  of  Defense  (AT&L),  August  8,  2007)  emphasis  on  maximizing 
the  commonality,  reuse,  and  effectiveness  of  modeling  and  simulation  data,  a 
new  model  must  be  established. 
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Reuse  can  lead  to  greater  efficiency  in  the  beginning,  middle  and  final  stages 
of  database  development.  Each  stage  has  the  potential  to  be  the  optimum  single 
capture  point.  The  single  capture  point  would  allow  maximum  reuse  with  the 
least  amount  of  effort.  The  beginning  stage  is  when  the  collection  of  raw  source 
data  is  received  from  the  suppliers.  By  utilizing  source  data  from  the  beginning 
stage,  time  and  cost  savings  are  seen  in  the  initial  source  data  acquisition  and 
collection  tasks.  However,  capturing  the  data  at  the  beginning  phase  would  only 
yield  savings  on  the  acquisitions  of  the  raw  data  products.  These  savings  in  cost 
are  important  but  do  not  include  the  non-recurring  expenses  (NRE)  of  the 
development  and  processing  done  during  the  later  stages.  The  middle  stage 
contains  the  meat  of  the  development  process  by  correcting  and  processing  the 
source  data  until  it  is  ready  for  compilation  into  a  run-time  database.  The  name 
middle  stage  is  misleading.  Because,  the  middle  stage  often  consumes  significant 
labor  and  time.  In  some  reports,  up  to  80%  of  the  cost  to  produce  the  database 
is  the  result  of  the  middle  stage.  The  final  stage  or  possible  capture  point  is  at 
the  completion  and  acceptance  of  the  run-time  database.  The  product  of  the  final 
stage  is  often  in  a  proprietary  format.  Because  of  the  proprietary  format,  reuse  is 
hampered  to  the  point  of  diminishing  returns. 

The  NPSI  team  found  that  the  best  place  to  archive  a  product  is  after  the 
middle  stage  is  complete,  where  the  source  data  is  refined,  correlated,  and  ready 
for  processing.  If  data  is  captured  at  the  end  stage,  reuse  is  extremely  difficult 
due  to  proprietary  formats.  Likewise,  the  first  stage  only  captures  twenty  to  thirty 
percent  of  the  database  costs  making  this  stage  an  underperforming  location  for 
a  return  on  investment.  At  the  discretion  of  the  primary  acquisition  program,  an 
interim  delivery  can  be  captured  by  the  NPSI  team  after  the  first  stage.  In  this 
case,  programs  on  a  parallel  acquisition  cycle  could  reuse  the  first  stage  data 
products. 

While  the  optimum  capture  point  is  after  the  middle  stage,  the  best  and 
acceptable  time  to  deliver  the  captured  data  products  is  after  the  acceptance  of 
the  run-time  database.  Once  the  run-time  database  is  completed,  and  the  results 
of  the  database  are  acceptable,  the  source  data  used  to  create  the  database  can 
be  captured  and  archived.  Data  deemed  acceptable  in  the  past  can  now  be 
reused  with  a  high  level  of  confidence  that  the  archived  data  will  be  of  value  to 
other  programs.  The  issue  in  this  approach  is  the  case  of  parallel  or  partially 
parallel  programs  effort  that  are  enhancing  similar  areas.  In  this  case,  the 
expansion  of  the  interim  datasets  option  will  maximize  the  effectiveness  of  NPSI. 

The  functional  diagram  in  Figure  1  illustrates  the  flow  of  data,  requirements, 
and  products  in  a  typical  NPSI  database  production  process.  Appendix  A  and 
Appendix  B  provide  more  detail  into  the  processes  involved  in  the  development  of 
an  NPSI  dataset  and  completion  of  a  run-time  database. 
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2.  NPSI  Dataset  Description 

An  NPSI  dataset  contains  the  combination  of  refined  source  data,  metadata 
descriptions,  and  data  license  information.  The  dataset  will  include  several 
different  industry  standard  data  types.  By  focusing  on  well-used  and  well- 
documented  industry  standards,  maximum  availability  and  reuse  can  be  achieved 
without  significant  cost  burden  to  the  program. 

Licenses  and  markings  are  provided  by  the  contractor  for  new  data 
acquisitions  allowing  visibility  of  ownership  and  direct  contact  to  the  specific 
vendor  in  the  case  that  data  is  in  need  of  future  licensing  expansion  or  uplift. 
Both  data  licenses  and  data  legacy  are  annotated  within  the  NPSI  metadata 
documentation.  The  following  paragraphs  are  high-level  descriptions  of  the  key 
elements  within  an  NPSI  dataset,  while  the  requirements  for  an  NPSI  dataset  is 
located  in  section  4. 

2.1  Dataset  Data  Types 

The  following  sections  describe  the  typical  components  of  an  NPSI  dataset. 
While  a  dataset  may  not  contain  all  of  the  data  types  listed,  the  goal  of  NPSI  is  to 
archive  a  dataset(s)  that  accurately  represents  the  source  data  required  to 
recreate  the  program's  run-time  database(s). 

2.1.1  Terrain  Data 

Terrain  data,  or  elevation  data,  is  a  grid  of  elevation  posts  at  specific  intervals 
indicating  the  height  of  the  terrain  at  each  post.  The  mosaic  of  these  terrain  data 
files  is  a  representation  of  the  earth's  surface.  Refined  terrain  data  can  hold 
several  corrections  including  spike  minimizations  and  hole  interpolations.  The 
refined  terrain  data  can  be  a  merge  of  several  different  terrain  data  collections. 
The  terrain  skin  created  from  the  terrain  data  is  one  of  the  critical  pieces  of 
correlation  used  in  ground  simulation.  Significant  labor  efforts  are  involved  in 
terrain  correlation.  The  archival  and  reuse  of  terrain  data  is  a  key  first  step  to 
better-correlated  database  products.  Depending  on  the  data's  source,  resolution, 
and  refinements,  the  terrain  data  is  delivered  in  different  standard  formats. 

2.1.2  Feature  Data 

Feature  data  represents  geographic  data  using  constructive  geometric 
primitives  such  as  point,  linear  (line),  and  areal  (polygon)  that  are  to  be 
integrated  or  overlaid  on  the  terrain  skin.  Refined  feature  data  includes  any 
adjustment  and/or  additions  that  have  been  made  to  the  original  source  data  to 
provide  better  correlation  with  imagery  or  other  source  data.  The  National 
System  for  Geospatial  Intelligence  (NSG)  Entity  Catalog  (NEC)  attribution  is 
desired  as  the  default  attribution  schema. 
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2.1.3  Imagery  Data 

Imagery  is  defined  by  U.S.  Code  Title  10,  §467  as: 

The  term  "imagery"  means,  except  as  provided  in  subparagraph  (B),  a 
likeness  or  presentation  of  any  natural  or  manmade  feature  or  related 
object  or  activity  and  the  positional  data  acquired  at  the  same  time  the 
likeness  or  representation  was  acquired,  including  -  (i)  products 
produced  by  space-based  national  intelligence  reconnaissance 
systems;  and  (ii)  likenesses  or  presentations  produced  by  satellites, 
airborne  platforms,  unmanned  aerial  vehicles,  or  other  similar  means. 
(B)  Such  term  does  not  include  handheld  or  clandestine  photography 
taken  by  or  on  behalf  of  human  intelligence  collection  organizations. 

Imagery  data  provided  in  an  NPSI  dataset  is  the  refined  version  of  that 
imagery  with  any  source  data  redundancies  resolved.  The  data  represents,  at  a 
minimum,  the  fidelity  and  resolution  delivered  for  the  application  and  platform. 
However,  it  is  desired  that  the  imagery  be  delivered  at  the  highest  resolution  of 
the  refined  source  data,  and  not  an  under  sampled  image  of  less  resolution. 

2.1.4  Raster  Material  Analysis  Data 

A  sensor  simulation  database  often  requires  the  analysis  of  raster  imagery  in 
multiple  bands  to  discern  the  material  type.  The  raster  material  analysis  data  is 
often  stored  and  labeled  as  a  material  map.  Material  maps  denoting  a  type  or 
mixture  of  types,  on  a  per-pixel  basis,  can  be  created  by  third  party  tools  and 
saved  into  an  image  file  for  future  use.  The  material  map  must  have  a  reference 
document  included  to  describe  the  meaning  of  each  pixel  value  within  the 
material  map.  The  material  data  references  in  an  NPSI  dataset  are  described  in 
the  metadata  Section  2.1.8  below. 

A  material  properties  database  is  populated  with  authoritative  reference 
documents  and  is  expandable  to  include  supplemented  authoritative  data  in  the 
future.  The  desire  to  form  a  common  standard  by  utilizing  the  Material  Properties 
Reference  Database  (MPRD)  Schema  is  common  among  other  DoD  training 
commands.  A  standard  material  library  is  essential  for  addressing  issues  of 
interoperability  and  validation  of  a  sensor  model. 

2.1.5  3D  Static  Models 

3D  static  models  can  be  generic  models  that  are  planted  at  fixed  locations 
either  randomly  or  by  structured  order.  The  generic  models  could  include  a 
typical  office  building,  a  church,  or  a  power  line  tower.  3D  static  models  can  also 
be  specific  models  captured  and  placed  to  represent  specific  features  at  specific 
places,  such  as  the  Statue  of  Liberty. 
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The  dataset  often  includes  any  alternate  versions  of  the  models,  the  levels  of 
detail  (LODs),  associated  texture  maps,  animation  controls,  and  articulated  parts, 
that  are  necessary  to  incorporate  the  model  into  follow-on  applications.  The  3D 
model  often  includes  geospatially  referenced  footprint  polygons.  The  model  origin 
point  is  the  (0,0)  point  within  the  3D  model.  The  model  origin  point  and/or 
footprint  area  for  each  one  of  the  3D  static  models  are  often  represented  as 
geospatial  feature  data  files.  The  origin  point  can  also  be  within  the  header  of  the 
model  file  itself.  Other  embedded  feature  data  attributes  of  the  3D  static  models 
include  the  disk  file  name,  relative  directory  location,  model  orientation, 
classification  code,  and  a  name  or  label. 

2.1.6  3D  Moving  Models 

3D  moving  models  are  often  seen  in  the  visual  scene  as  entities  such  as 
planes,  tanks,  ships,  and  people.  The  dataset  would  include  alternate  versions  of 
the  models  such  as  differing  paint  schemes  and  damaged  states,  as  well  as 
articulations,  animation  controls,  LODs,  and  switches. 

2.1.7  3D  Airfield  Models 

Airfields  are  considered  rather  large  3D  static  models.  The  size  of  an  airfield 
imposes  new  modeling  considerations  to  be  taken  into  account  when  the  airfield 
is  developed.  Airfields  are  often  subject  to  projection  errors  when  converting 
between  projections  and  datums  of  runtime  systems.  Therefore,  great  care  must 
be  taken  when  attributing  and  referencing  a  3D  airfield.  If  multiple  files  are  used 
to  represent  an  airfield,  it  is  common  to  have  an  airfield  master  file  to  externally 
reference  all  other  3D  model  files  built  for  the  airfield. 

While  not  all  systems  support  the  OpenFlight®  file  format  natively,  the  format 
has  become  a  significant  standard  within  the  industry.  Therefore,  examples  of 
OpenFlight®  airport  hierarchy  and  structure  recommendations  are  presented  in 
Appendix  C  and  recommended  light  point  naming  conventions  are  shown  in 
Appendix  D. 

2.1.8  NPSI  Metadata 

An  extensible  markup  language  (XML)  metadata  file  accompanies  each  NPSI 
dataset  distribution.  The  schema  of  this  metadata  is  defined  in  the  following 
document,  NAVAIR  Portable  Source  Initiative  Standard  for  Reusable  Source 
Dataset  Metadata  V2.4.  NPSI  metadata  is  an  overall  wrapper  of  the  NPSI  dataset 
providing  descriptions  of  all  files  included  within  the  dataset  in  a  single  XML  file. 
Licensing  and  security  classification  elements  are  present  at  both  the  dataset  and 
the  individual  file  element  level  allowing  an  accurate  description  of  both  individual 
files  and  the  overarching  dataset.  The  location  of  the  data  files  and  thumbnails 
are  identified  within  the  file  elements  enabling  the  metadata  file  to  map  smoothly 
into  a  catalog  system.  Data  groups  associate  similar  file  elements  together  within 
the  dataset  description. 

The  NPSI  metadata  references  material  properties  using  a  lookup  index  to  the 
MPRD  data  files.  The  material  data  file  XML  format  is  defined  in  the  NAVAIR 
Portable  Source  Initiative  Standard  for  Material  Properties  Reference  Database 
1/2.2.  MPRD  schema  and  is  an  extension  of  Material  Markup  Language  (MatML). 
MatML  was  a  National  Institute  of  Standards  and  Technology  (NIST)  initiative 
supported  by  a  community  of  materials  engineers  and  scientists.  MPRD  supports 
multi-spectral  radiometry  properties  and  multi-component  materials. 
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2.2  NPSI  Dataset  Acceptance 

The  content  of  the  NPSI  dataset  will  be  tested  and  evaluated  for  completeness 
and  accuracy  by  the  NPSI  team.  The  primary  criterion  for  evaluation  is 
verification  that  the  dataset  sufficiently  supports  the  development  of  follow-on 
databases  with  a  minimum  of  redundant  efforts.  Further  information  on 
requirements  can  be  found  in  Section  4  and  Section  6.  Interim  datasets,  as 
described  in  Section  4.3,  will  be  verified  for  geospatial  coordinates,  license 
information,  and  an  accurate  file  list.  Unlike  final  NPSI  datasets,  interim  datasets 
do  not  require  NPSI  formatted  metadata. 

2.3  NPSI  Dataset  Distribution 

Once  the  NPSI  dataset  is  accepted,  the  NPSI  data  will  be  ready  for 
distribution  to  future  programs.  The  government  will  determine  the  NPSI  dataset 
components  that  are  to  be  provided  as  government  furnished  information  (GFI) 
to  the  program,  and  the  selected  data  will  be  delivered  to  the  supplier(s)  in 
accordance  with  the  Federal  Acquisition  Regulations  (FAR)  government  furnished 
property  (GFP)  clauses  and  the  contract  GFI  and  GFP  clauses. 

The  program's  database  requirements  (e.g.,  airfields,  targets)  are  presented 
in  the  statement  of  work  (SOW)  and  specification.  Likewise,  requirements  for 
interoperable  correlation  are  presented  in  the  SOW  and  specification  of  the 
contracted  effort.  Regardless  of  the  NPSI  dataset  distributed  and  received,  the 
correlation,  fidelity,  and  coverage  requirements  for  the  production  and 
development  of  the  database  per  the  contract  remain  the  supplier's 
responsibility.  Database  suppliers  are  required  to  meet  the  requirements 
specified  within  the  contract  regardless  of  GFI  or  GFP  quality.  In  these  cases, 
additional  data  can  be  procured  or  created  by  the  contractor  to  meet  the 
requirements  of  the  contract. 
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3.  Follow  On  Database  Production 

Follow  on  database  suppliers  have  tool  sets  in  place  (commercial  off  the  shelf 
(COTS)  and/or  proprietary)  that  can  utilize  the  data  formats  incorporated  into 
NPSI  datasets.  The  database  production  process  is  similar  to  that  described  in 
Appendix  A.  The  database  developed  from  the  NPSI  data  is  optimized  to  support 
the  specific  aircraft  missions  and  maneuvers.  The  content  of  the  database  is  sized 
and  structured  for  optimum  performance. 

3.1  Dataset  Reuse 

In  many  cases,  even  reused  datasets  require  some  development  effort. 
Programs  that  limit  database  production  to  pure  reuse  of  an  NPSI  dataset 
essentially  accept  the  previous  programs  requirements  with  respect  to  fidelity, 
gaming  areas,  and  culture  data.  If  a  prior  program  produced  a  database 
description  document  (DBDD)  then  the  DBDD  can  be  provided  as  a  description  of 
the  prior  program  requirements  and  extents.  A  process  similar  to  the  original 
acceptance  process  will  be  used  to  accept  the  database  created  from  the  reused 
dataset.  The  follow-on  supplier  is  expected  to  verify  that  the  database  is 
sufficiently  interoperable  with  previous  databases.  The  NPSI  dataset  and  the  run¬ 
time  database  are  tested  for  performance  in  a  networked  or  standalone 
environment  based  on  the  requirements  of  the  contract.  If  there  were  no 
modifications  or  additions  of  refined  source  data  to  the  dataset  then  there  is  no 
need  for  an  NPSI  delivery  back  to  the  archive.  In  these  cases,  the  contract  data 
requirements  list  (CDRL)  for  NPSI  delivery  should  be  marked  as  an  option. 

3.2  Possible  NPSI  Feedback  and/or  Extensions 

There  is  a  possibility  that  subsequent  database  efforts  will  require  the  addition 
of  a  new  data  type(s)  within  an  NPSI  dataset  and  expanded  descriptions  within 
the  NPSI  DPS.  This  request  may  result  if  new  forms  of  data  have  become 
available  since  the  creation  of  the  original  NPSI  dataset  (e.g.,  technology 
enhancements,  improved  imagery  formats,  material  encoded  texture  maps,  etc.). 
As  with  the  original  philosophy  of  NPSI,  it  is  important  to  capture  the  work  done 
and  new  data  types  available  for  future  reuse.  Incorporating  this  new  data  so 
that  the  development  efforts  are  not  repeated  on  subsequent  efforts  provides 
cost  savings  to  future  programs. 

Upon  determining  that  additional  data  type(s)  are  required  within  the  dataset 
archive,  the  supplier  shall  notify  the  government  manager  of  the  NPSI  data 
archive  for  consideration.  Incorporating  additional  data  type(s)  into  the  NPSI  DPS 
and  the  NPSI  archive  will  be  determined  based  on  the  data  type(s)  involved.  A 
determination  will  be  made  by  the  NPSI  team  to  add  the  new  data  type(s), 
replace  previous  data  (again  depending  on  the  nature  of  the  new  data  type(s)), 
or  deny  the  request  to  store  the  new  data  type(s).  The  NPSI  DPS  will  also  be 
updated  to  include  any  information  that  will  make  it  easier  for  subsequent 
suppliers  to  make  use  of  the  data. 
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4.  NPSI  Dataset  Requirements  and  Components 

The  purpose  of  the  NPSI  standardization  is  to  lower  the  total  life  cycle  cost,  to 
encourage  interoperability,  and  to  open  simulation  device  architecture.  NPSI  will 
standardize  on  common  data  formats  utilized  by  industry  rather  than  developing 
a  new  data  format.  By  adhering  to  the  open  architecture  strategy  described 
below,  NAVAIR  will  not  be  forced  to  use  a  single  source  throughout  the  life  cycle 
of  the  program. 

All  data  shall  have  the  data  license  rights,  all  limitations  associated  with  the 
data,  and  the  contractor  point  of  contact  identified  and  documented.  The 
documented  data  shall  be  stored  in  a  text  document  at  the  root  of  the  dataset 
folder,  documented  in  the  NPSI  metadata,  and  marked  on  the  physical  media  as 
part  of  the  NPSI  dataset  delivery. 

For  all  GFI  data,  the  documentation  shall  reference  GFI  source  data  lineage. 
The  NPSI  dataset(s)  delivery  is  in  addition  to  the  run-time  database(s).  It  is 
desirable  for  these  two  items  to  be  delivered  against  the  same  CDRL.  Flowever, 
this  will  be  determined  by  the  contract. 

The  contract  is  desired  to  have  the  following  DFARS  clauses  attached, 
252.227-7013,  252.227-7015,  252.227-7022,  252.227-7025,  and  252.227-7037, 
however,  each  contract  should  be  evaluated  for  applicability  of  each  clause. 


4.1  NPSI  Dataset 

All  refined  source  data  required  to  re-create  the  delivered  run-time  databases 
(e.g.  visual,  sensor,  semi-automated  forces,  etc.)  shall  be  delivered  to  the  NPSI 
archive  as  a  compliant  NPSI  dataset.  All  NPSI  data  shall  have  a  GEOGRAPFIIC 
(UNPROJECTED)  LAT/LONG  projection  and  World  Geodetic  System  (WGS)-84 
datum.  The  data  within  the  NPSI  dataset  shall  be  delivered  in  the  following 
formats: 


Terrain:  Digital  Terrain  Elevation  Data  (DTED)  format 

(National  Imagery  and  Mapping  Agency, 
2000),  or  lossless  GeoTIFF  (Ritter  &  Ruth, 
2000)  in  8-bit,  16-bit,  or  32-bit  in  signed 
integer,  or  floating-point  gridded  matrix 
intensity  map. 

Features:  ESRI®  Shapefile  format  (Environmental 

Systems  Research  Institute,  Inc,  1998). 

Imagery:  Lossless  GeoTIFF  format  (Ritter  &  Ruth, 

2000):  8-bit,  or  16-bit,  unsigned  integer  pixel 
representation. 

Raster  Material  Data:  Lossless  GeoTIFF  format  (Ritter  &  Ruth, 

2000):  8-bit,  or  16-bit,  unsigned  integer  pixel 
representation. 

Models  and  Airfields:  OpenFlight®  (Presagis,  2009)  version  16.0 

(or  later)  with  RGB,  RGBA,  JPEG,  DDS,  DXTn, 
FXTn,  or  TIF  textures. 
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Media  Type  (Delivery):  DVD  or  External  Hard  Drive  with  USB  or 

eSATA  interface.  USB3.0  is  desired.  Media 
shall  be  marked  with  distribution  rights  and 
license  type. 

4.2  Raw  Source  Data  Examples 

•  DTED:  level  1,  2,  3,  4,  or  5 

•  Light  detection  and  ranging  (LIDAR)  point  cloud  data 

•  Controlled  Image  Base®:  CIB®  1,  5,  10 

•  National  Imagery  Transmission  Format  (NITF)  data  received  from  National 
Geospatial  Intelligence  Agency  (NGA) 

•  Commercial  satellite  image  library  products: 

o  Ikonos  panchromatic  and  multispectral 
o  GeoEye  panchromatic  and  multi-spectral 
o  Quickbird  panchromatic  and  multi-spectral 
o  WorldViewl  panchromatic  and  multi-spectral 
o  WorldView2  panchromatic  and  multi-spectral 
o  RapidEye 

o  Indian  Remote  Sensing  (IRS) 
o  Spot 
o  LandSat 

•  Aerial  photography  data  from  various  vendors 

•  Foundation  Feature  Data  (FFD),  Digital  Feature  Analysis  Data  (DFAD),  Vector  Map 
(VMAP),  Urban  Vector  Map  (UVMAP) 

•  Vector  Product  Format  (VPF) 

•  TopScene  Data  in  open  image  formats  such  as  GeoTIFF  and  NITF 

•  NPSI  archived  producer  level  data  (raw) 

•  NPSI  interim  datasets  (raw) 

•  SEDRIS  Transmittal  Format  (STF),  which  can  be  converted  using  core  SEDRIS 
tools  or  COTS  vendor  toolsets 

4.3  NPSI  Interim  Datasets 

All  raw  source  data,  as  listed  in  section  4.2,  that  is  purchased  by  the 
contractor  team  for  the  program  is  considered  an  interim  dataset.  For  interim 
datasets  cumulatively  valued  over  $50,000.00,  early  delivery  to  NPSI  is 
requested.  Interim  datasets  will  be  stored  within  the  NPSI  archive  until  the 
official  NPSI  dataset(s)  delivery  from  the  program  is  received.  At  that  time,  the 
interim  dataset  will  be  permanently  backed  up  to  media  and  will  no  longer  be  an 
actively  searchable  or  distributable  dataset  unless  specifically  requested.  If 
interim  datasets  are  anticipated,  individual  CDRLs  or  CLINs  will  be  utilized  to 
purchase  the  data,  enabling  other  government  programs  to  make  use  of  the  raw 
source  data  upon  receipt. 
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4.4  Open  Source  Data  Preparation  Components 

The  preparation  of  source  data  accounts  for  a  significant  effort  in  the 
generation  of  a  run-time  geo-specific  database.  Correlation  is  a  historical  problem 
with  source  data,  including  NGA  products  mentioned  in  Section  4.2  above.  The 
following  labor-intensive  processes  address  these  issues  and  can  be  performed 
using  third  party  tools.  By  requiring  the  following  processes  for  standardization, 
the  government  can  more  readily  reuse  the  product  of  a  dataset  delivery.  It  is 
important  to  discriminate  which  processes  are  to  be  done  only  once  and  which 
processes  are  best  done  on  a  per  run-time  database  publication  occurrence.  The 
following  sections  describe  processes  done  only  once  resulting  in  data  that  is 
subsequently  reused. 

4.4.1  Terrain 

4.4. 1.1  Terrain  Merge 

Merging  the  terrain  between  different  resolutions  allows  the  simulation  to 
have  the  most  realistic  terrain  simulation.  Familiarization  of  a  given  area  is  often 
done  based  on  the  appearance  of  the  terrain  features.  While  the  terrain  data 
most  used  in  Navy  simulation  varies  with  each  training  device,  every  pilot 
requests,  and  in  many  cases  demands,  increased  fidelity  and  realism.  Terrain 
merge  is  the  method  of  taking  a  base  elevation,  such  as  DTED  2  representing  30- 
meter  elevation  post  intervals,  and  merging  with  a  high  fidelity  elevation,  such  as 
LIDAR  representing  1-meter  elevation  post  spacing.  The  final  product  will  have 
high  fidelity  elevation  data  in  the  area  of  interest  and  a  lower  fidelity  background. 
Terrain  merge  shall  be  performed  as  required  and  any  changes  shall  be  captured 
in  the  formats  described  in  Section  4.1. 

4.4. 1.2  Terrain  Edits 

Edits  to  terrain  data  may  include  flattening  the  terrain  for  lakes,  correlating 
terrain  to  rivers,  incorporating  cut  and  fill  for  roads,  smoothing  spikes  and  holes, 
or  correcting  the  underlying  source  data  that  mismatches  between  the 
boundaries  of  files.  Terrain  edits  performed  shall  be  captured  in  the  formats 
described  in  Section  4.1.  For  these  edits,  it  is  also  requested  that  the  original 
elevation  data  also  be  provided. 

4.4.2  Features 

Vector  products  such  as  DFAD  and  VMAP  designate  point,  linear,  and  areal 
features.  These  vector  representations  typically  do  not  match  imagery,  and  the 
work  associated  with  correlating  features  to  the  imagery  is  labor-intensive. 
Corrections  are  made  to  source  data  in  applications  that  map  features  with 
imagery.  Modifications  made  to  feature  data  shall  be  saved  in  ESRI®  Shapefile 
format  with  GEOGRAPHIC  (UNPROJECTED)  LAT/LONG  projection  and  WGS-84 
datum  for  follow-on  programs.  Terra  in -feature  correlation  shall  be  performed  as 
required. 

DoD  Information  Technology  Standards  and  Profile  Registry  (DISR)  provide 
standards  for  Geospatial  data.  One  such  standard  for  attribution  is  the  NEC 
(National  System  for  Geospatial  Intelligence,  2009)  attribution  standard.  NEC 
attribution  is  desired  to  allow  common  identification  of  feature  data. 
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4.4.3  Imagery 

4.4.3. 1  Ortho-Rectification 

Imagery  may  need  to  be  ortho-rectified,  a  correction  that  accounts  for  reiief 
dispiacement  and  distortions  caused  by  the  terrain.  Ortho-rectification  shaii  be 
performed  as  required  by  the  contract. 

4.4. 3. 2  Image  Rectification 

Image  rectification  warps  an  image  to  match  controi  points.  This  process 
addresses  geometric  inaccuracies  such  as  a  road  in  one  image  that  is  not 
geometricaiiy  continuous  with  the  same  road  in  an  adjoining  photograph.  Image 
rectification  shaii  be  performed  as  required  by  the  contract. 

4.4. 3. 3  Image  Normalization  and  Color  Balancing 

Coior  discontinuities  are  often  observed  in  photographs  taken  at  different 
times  and  can  be  a  distraction  in  training.  Image  normaiization  is  the  process  of 
evening  out  the  brightness  within  individuai  images.  Coior  baiancing  is  the 
process  of  appiying  tonai  and  contrast  adjustments  to  increase  coior  consistency 
over  the  range  of  the  photographs  or  images.  Image  normaiization  and  coior 
baiancing  shaii  be  performed  as  required  by  the  contract. 

4.4. 3. 4  Imagery  Merge 

Oftentimes,  source  imagery  comes  in  two  separate  fiies:  a  high-resoiution 
panchromatic  image,  and  a  iower  resoiution  muiti-spectrai  image.  These  two 
images  shaii  be  merged  into  one  image  prior  to  ingestion  into  a  run-time 
database  generation  system.  Imagery  merge  shaii  not  be  done  when  the 
resoiution  ratio  exceeds  6:1.  NPSI  deiivery  of  imagery  data  before  an  imagery 
merge  is  not  required. 

4.4. 3. 5  Feathering 

When  inserting  high-resoiution  imagery  into  an  area  of  iower  resoiution 
imagery,  a  smoothing  aigorithm  for  feathering  boundaries  is  often  used  to  avoid 
a  sharp,  high-contrast  iine  where  one  image  ends  and  another  begins.  If 
feathering  was  compieted,  then  the  feathered  images  shaii  be  deiivered,  and  finai 
pre-feathered  images  shaii  be  deiivered  if  avaiiabie. 

4.4. 3. 6  Image  Masks 

Mask  fiies  can  be  used  to  feather  or  biend  data  fiies  together.  The  image 
mask  consists  of  a  singie  iayer  image  that  aiiows  for  gradient  biending  of  the  top 
image  with  the  background  images.  This  method  is  capabie  of  removing 
discrepancies  with  the  top  image  and  repiacing  the  data  in  a  more  dynamic 
approach  aiiowing  future  modification  without  extensive  reprocessing.  If  image 
masks  were  used,  then  the  image  masks  shaii  be  deiivered. 

4.4. 3. 7  Imagery  File  Size 

There  is  a  known  fiie  size  iimitation  of  2  GB  for  GeoTIFF  fiies.  In  the  event  an 
image  fiie  exceeds  this  iimit,  the  image  shaii  be  broken  into  severai  tiies  under 
the  size  iimit.  Image  fiies  shaii  remain  uncompressed  resuiting  in  a  iossiess  data 
capture. 
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4.4.4  Raster  Material  Data 

Multi-layer  raster  material  data  constructed  as  material  maps  shall  be 
included  in  the  NPSI  dataset.  The  material  layers  and  the  mixture  layers  shall  be 
delivered  merged  into  a  single  image  file.  The  pixel  values  within  the  material 
layer  shall  represent  a  single  material.  The  pixel  values  within  the  mixture  layers 
represent  the  percentage  of  coverage  of  the  associated  material  layer.  For  every 
two  material  layers  one  mixture  layer  is  required. 

If  new  references  are  used  or  old  references  are  requested  to  be  updated 
then  those  new  metadata  files  shall  be  included  in  the  NPSI  dataset.  The  NPSI 
material  library  in  XML  format  is  defined  in  the  NPSI  MPRD  per  section  2.1.8 
above.  Therefore,  all  reference  document(s)  provided  with  the  NPSI  dataset  shall 
be  provided  in  XML  format  and  validated  against  the  MPRD  Schema. 

4.4.5  3D  Static  Feature  Models 

3D  static  feature  models  are  either  built  from  scratch,  reused,  or  modified.  In 
the  case  the  3D  models  are  anticipated  to  be  reused,  additional  training-relevant 
data  may  be  necessary  to  meet  the  fidelity  specified  within  the  contract. 

3D  static  feature  models  shall  be  delivered  as  required.  All  geospecific  models 
must  have  defined  the  origin  of  the  model,  the  current  projection,  and  datum 
within  the  OpenFlight®  Fleader.  The  models  in  the  simulation-prepared  source 
data  shall  be  in  OpenFlight®  version  16.0  (or  later)  at  all  modeled  levels  of  detail 
and  states.  The  model  origin  point  and/or  footprint  area  for  each  one  of  the  3D 
static  models  shall  be  represented  geospatially  in  the  formats  of  feature  data. 
Feature  data  descriptions  of  the  3D  static  models  shall  include,  as  attributes,  the 
disk  file  name,  the  relative  directory  location,  and  the  model  orientation. 

All  textures  associated  with  a  single  model  shall  have  the  same  relative  path 
and  shall  be  included  in  the  dataset.  All  sensor  textures  associated  with  a  single 
model  shall  be  included  in  the  dataset.  Sensor  textures  are  desired  to  have  the 
name  exactly  match  the  equivalent  regular  texture  with  the  inclusion  of  '.sensor' 
in  the  name  (e.g.,  door.rgb  and  door. sensor. rgb).  Unused  textures  shall  be 
removed  from  the  model's  texture  palette  and  texture  directory.  All  textures  shall 
be  formatted  in  compliance  with  section  4.1  and  have  a  size  that  is  a  power  of  2 
in  each  dimension.  Model(s)  shall  be  facing  in  the  positive  Y  direction.  All  empty 
nodes  shall  be  removed. 

4.4.6  3D  Moving  Models 

3D  moving  models  are  either  built  from  scratch,  reused,  or  modified.  In  the 
case  the  3D  models  are  anticipated  to  be  reused,  additional  training-relevant 
data  may  be  necessary  to  meet  the  fidelity  specified  within  the  contract. 

3D  moving  models  shall  be  delivered  as  required.  The  models  in  the 
simulation-prepared  source  data  shall  be  in  OpenFlight®  version  16.0  (or  later) 
at  all  modeled  levels  of  detail  and  states.  The  OpenFlight®  model  shall  function 
properly  as  an  OpenFlight®  model.  If  extracted  into  OpenFlight®  from  an 
alternate  format,  the  OpenFlight®  model  shall  be  verified  for  correctness,  which 
includes  all  aspects  of  the  model  including  lights  and  articulated  parts. 
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All  textures  for  a  model  shall  have  the  same  relative  path  and  be  included  in 
the  dataset.  External  referenced  models  shall  have  the  textures  relative  to  the 
referenced  model.  All  sensor  textures  shall  be  included  and  it  is  desired  to  have 
the  name  exactly  match  the  equivalent  regular  texture  with  the  inclusion  of 
'.sensor'  in  the  name  (e.g.,  door.rgb  and  door.sensor.rgb).  Unused  textures  shall 
be  removed  from  the  model's  texture  palette  and  texture  directory.  All  textures 
shall  be  formatted  in  compliance  with  Section  4.1  and  have  a  size  that  is  a  power 
of  2  in  each  dimension.  Model(s)  shall  be  facing  in  the  positive  Y  direction.  All 
empty  nodes  are  removed. 

4.4.7  3D  Airfield  Models 

All  3D  airfield  complex  models  are  either  built  from  scratch,  reused,  or 
modified.  In  the  case  the  3D  airfield  models  are  anticipated  to  be  reused, 
additional  training  relevant  data  may  be  necessary  to  meet  the  fidelity  specified 
within  the  contract.  Airfield  models  shall  be  included  as  3D  static  feature  models 
per  Section  4.4.5,  described  above,  in  OpenFlight®  format  version  16.0  or  higher 
with  all  LCDs,  texture  maps,  animation  controls,  and  articulations.  All  runway 
markings  shall  be  prepared  and  stored  under  separate  object  or  group  nodes. 
Runway  markings  shall  not  be  "cut  in."  Airfield  light  points  reference  the  light 
point  palette  and  the  name  or  appearance  of  given  light  type  is  desired  to  be  as 
descriptive  as  possible  as  shown  in  Figure  5,  (see  Appendix  C.3). 

While  modeling  techniques  are  not  dictated,  airfield  complexes  are  to  be 
modeled  in  such  a  way  as  to  simplify  segregation  and  desegregation  of  all 
features.  At  a  minimum,  each  feature  type  is  contained  under  an  appropriately 
named  parent  group  node. 

It  is  recommended  that  each  feature  be  modeled  individually  with  its  own 
origin  and  externally  referenced  and  positioned  into  a  master  file,  including  but 
not  limited  to  the  following:  runways  and  tarmacs  with  markings,  foot  to  go 
markings,  lighting  systems,  buildings,  towers,  and  beacons. 

The  airfield  shapefile  shall  reference  each  model  with  a  separate  point 
feature.  Each  point  feature  shall  use  either  "file"  or  "code"  as  the  index  tag  and 
the  filename  in  the  data  field.  Each  shapefile  shall  conform  to  Section  4.4.2 
requirements. 


14 

WUNCLASSIFIEDW 


NPSI  DPS  2.2 


5.  Deliverables 

5.1  NPSI  Dataset 

When  the  run-time  database  is  finalized  and  accepted,  the  initial  supplier  shall 
provide  the  final  NPSI  dataset(s)  within  four  weeks  unless  specifically  stated 
otherwise  within  the  contract.  All  value-added  source  data  used  to  produce  the 
run-time  database(s)  shall  be  delivered  in  formats  as  referenced  in  Section  4.1. 
These  delivery  items  shall  be  consistent  with  the  vendor  independent  output 
processes  described  in  Section  2. 

5.2  NPSI  Interim  Dataset 

The  interim  dataset  shall  be  delivered  within  two  weeks  of  delivery  receipt 
and  factory  acceptance  of  the  COTS  or  Non-COTS  raw  source  data.  The  interim 
dataset  shall  include  a  copy  of  the  procurement  and  usage  license  agreement. 
NPSI  metadata  is  desired  but  not  required  with  the  interim  dataset. 

5.3  Documentation 

An  NPSI  metadata  document  shall  be  provided  for  each  dataset  per  Section 
2.1.8.  If  the  DBDD  is  developed,  available,  and  delivered  to  the  program  then  the 
DBDD  shall  be  included  with  the  NPSI  dataset.  The  data  licenses  from  the 
contractor  for  the  new  (non-GFI)  data  within  the  dataset  shall  be  provided,  in 
accordance  with  DFARS  clause  252.227-7013,  and  referenced  by  the  NPSI 
Metadata  documents  identified  in  Section  2.1.8. 
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6.  Verification  &  Validation 

The  NPSI  team  will  verify  that  all  data  delivered  includes  the  value-added 
components.  The  program's  visual  subject  matter  expert  (SME)  is  responsible  to 
validate  the  correlation  of  the  dataset  and  the  run-time  database.  The  NPSI  team 
estimates  two  weeks  to  review  each  dataset.  However,  the  exact  review  time 
allowed  will  be  described  within  the  contract's  CDRL. 

The  NPSI  verification  and  validation  process  shall  be  used  to  verify  the  NPSI 
data  is  in  the  required  formats  and  can  be  ingested  into  the  database  generation 
system  if  delivered  as  part  of  the  contract.  The  verification  will  reference 
documentation  from  the  contractor  such  as  the  DBDD  that  describes  the  data, 
and  the  process  used  to  output  the  NPSI  data.  The  NPSI  team  will  test  the 
validity  of  the  NPSI  metadata.  The  testing  will  validate  if  the  metadata  accurately 
represents  the  dataset  on  the  disk.  Below  are  the  current  criteria  questions  asked 
with  regard  to  dataset  verification  and  validation.  The  tools  listed  are  for 
explanation  purposes  only  and  do  not  reflect  a  requirement  for  the  said  tools. 

6.1  Metadata 


6. 2  Requirement 

6.3Result 

Is  the  metadata  valid  against  the  current  NPSI  schema  file 
(*.xsd)? 

Yes/No 

Are  the  files  listed  in  the  metadata  provided  on  the  disk? 

Yes/No 

Are  the  files  listed  on  the  disk  provided  in  the  metadata? 

Yes/No 

6.3.1  Metadata  Sample  Validation  Procedure 


Step 

Action 

Procedure  and  Notes 

1 

Validate  provided 
metadata  file  against 
given  schema  file 
(xsd). 

Open  the  xml  file  and  then  associate  the  xml 
file  to  the  schema  (xsd). 

2 

Validate  delivered 
metadata  (xml) 
against  current  NPSI 
schema  (xsd). 

Validate  contractual  requirement.  If  the 
provided  xsd  file  is  the  current  NPSI  xsd  then 
skip  to  3.  Otherwise,  the  file  must  be 
remapped  into  the  current  NPSI  schema 
format.  After  translation,  validate  the 
metadata. 

3 

Ingest  the  metadata 
into  the  NPSI  catalog. 

Open  the  NPSI  catalog  and  test  the 
connection  to  the  server.  Select  the  file  to  be 
ingested  and  start  ingest.  When  complete, 
view  the  dataset  by  selecting  the  dataset  ID 
and  inspect  the  catalog  entries  to  verify  the 
data  was  successfully  ingested  into  the 
database. 
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4 

Run  the  quality 
assurance  (QA)  tool. 

Using  the  Dataset  QA  tool,  select  the  dataset 

ID  to  be  checked  and  then  select  "QA  Task". 

Confirm  that  the  following  QA  options  are 
checked:  Check  bounding  coordinates 
consistencies.  Check  for  all  mandated  XML 
fields.  Validate  file  path.  Get  companion  files, 
and  Calculate  transfer  size.  Then,  select 
"Start  QA". 

5 

Create  separate 
outlines  of  the 
metadata. 

Select  the  correct  dataset  ID  and  use  the 
publish  KML  tool  to  export  KML  and  KMZ 
outlines  for  each  data  type. 

6 

Do  tasks  on  the  other 
validation  items 
[imagery,  elevation, 
materials,  shapes] 
then  return. 

Proceed  to  the  imagery,  elevation,  materials, 
and  shapefiles  procedures  and  then  return 
here. 

7 

Verify  continuity  in 
Google  Earth  or 

ESRI®  GIS  Globe 
tool. 

Typical  colors  used  for  KML  or  KMZ  output: 

•  16m  (and  above)  =  Green  (0,170,0) 

•  8m  =  Yellow  (255,255,0) 

•  4m  =  Orange  (255,170,0) 

•  2m  =  Red  (255,  0,  0) 

•  Im  =  Deep  Red  (170,0,0) 

•  0.5m  =  Dark  Gray/Brown  (125,60,0) 

•  0.25m  =  White  (255,255,255) 

•  1  ft  or  less  =  White  (255,255,255) 

6.4  General  Geospatial  Information 


Requirement 

Result 

Verify  all  files  have  a  projection  of  geographic  (unprojected) 
latitude  and  longitude. 

Yes/No 

Verify  all  files  have  a  datum  of  WGS84. 

Yes/No 

Does  the  resolution  of  the  data  match  the  filename,  folder 
and/or  metadata  description? 

Yes/No 

6.4.1  General  Geospatial  Information  Sample  Procedure 


Step 

Action 

Procedure  and  Notes 

1 

Verify  projection  and 
datum. 

In  ArcMap  use  python  scripts  to  do  data 
verification  on  all  directories  and  sub 
directories  for  all  *.tif,  *.shp,  and  *.dt#  files 

2 

Verify  Resolution  with 
respect  to  the  folder 
or  file  name. 

Using  the  output  of  the  first  script,  in  ArcMap 
run  a  second  script  analyzing  the  calculated 
resolution  against  the  folder  name.  Repeat 
with  file  name  instead  of  folder  name  and 
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analyze  the  results. 


6.5  Imagery 


Requirement 

Result 

Does  the  metadata  match  the  image  data  provided? 

Yes/No 

Are  all  image  files  continuous? 

Yes/No 

Are  the  images  color  balanced? 

Yes/No 

Are  different  seasons  present  as  overlapping  areas? 

Yes/No 

Are  the  images  blended? 

Yes/No 

If  the  images  are  not  blended,  does  each  image  provide  a 
blend  mask  file? 

Yes/No 

If  the  images  are  not  blended,  do  the  images  and  masks 
overlay  correctly? 

Yes/No 

6.5.1  Imagery  Sample  Procedure 


Step 

Action 

Procedure  and  Notes 

1 

Overlay  the  KML  files 
from  ArcMap  and  the 
KML  files  from  the 
catalog  in  Google 

Earth. 

This  will  provide  verification  that  the  data  on 
the  disk  matches  the  data  in  the  metadata. 

For  the  Tiff  files,  select  the  newly  created 
KML/KMZ  files  and  open  them  in  Google 

Earth. 

2 

Validate  the  continuity 
of  the  Image  files. 

Compare  the  KML  files  from  ArcMap  to  the 

KML  files  from  the  catalog. 

Open  the  KML's  (only)  in  Google  Earth. 

Validate  in  Google  Earth  that  these  data 
blocks  match  by  turning  on  and  off.  Now 
bring  the  KMZ's  from  the  catalog  directory 
into  Google  Earth  and  verify  there  are  no 
holes  in  the  imagery  they  provided. 

3 

Open  the  Shapefiles 
created  by  the 

Preview  Procedure  in 
ArcMap. 

In  ArcMap  make  the  original  dataframe  layer 
active.  Right  click  one  of  the  data  layer 
subsets  and  select  by  attributes. 

4a 

Query  the  files  to 
ensure  the  resolution 
of  the  file  matches  the 
filename. 

In  ArcMap,  copy/paste  in  all  queries  (below), 
verify  and  apply.  Select  "Selected"  in  Show. 
Verify  any  results. 
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4b  I  cont.  I  (("RASTER_NAM"  LIKE  '%quartermeter%') 

AND  (  "RES_NAM"  <>  '1  foot  or  less')) 
or 

(("RASTER_NAM"  LIKE  '%halfmeter%')  AND  ( 
"RES_NAM"  <>  '0.5  meter')) 
or 

(("RASTER_NAM"  LIKE  '%_lm%')  AND  ( 
"RES_NAM"  <>  '1  meter')) 
or 

(("RASTER_NAM"  LIKE  '%_2m%')  AND  ( 
"RES_NAM"  <>  '2  meter')) 
or 

(("RASTER_NAM"  LIKE  '%_4m%')  AND  ( 
"RES_NAM"  <>  '4  meter')) 
or 

(("RASTER_NAM"  LIKE  '%_8m%')  AND  ( 
"RES_NAM"  <>  '8  meter')) 
or 

(("RASTER_NAM"  LIKE  '%_16m%')  AND  ( 
"RES_NAM"  <>  '16  meter')) 

In  ArcMap,  create  a  data  frame  called  "OTW 
and  OTW  Mask  files"  and  make  this  data 
frame  active.  Copy  or  drag  the  separated 
OTW  and  OTW  Mask  files  from  the  other  data 
frame  layers  into  this  layer. 

Select  by  location  features  from  the  OTW 
shapefile  that  intersect  the  matching  OTW. 

5b  cont.  Open  the  attribute  table  for  the  data  frame 

using  the  selected  OTW_Shapefile.  Select  the 
option  "Switch  Selection"  and  "Show 
Selected". 

If  there  is  nothing  selected  then  the  data 
matches. 

If  there  are  selected  images  and  the  imagery 
is  not  16m  or  have  "_transition"  appended  to 
the  filename  (this  means  is  blended  already 
and  doesn't  need  a  mask)  then  copy  the  list 
and  make  a  note  of  it  in  the  QA  spreadsheet. 


Repeat  this  step  for  each  resolution. 


6 

Create  thumbnails. 

Run  the  Python  script  for  this  purpose. 

7 

Create  a  KMZ  file  with 
the  thumbnails  to 
preview  the  data. 

If  possible,  remap  the  new  thumbnail  data  to 
the  thumbnail  directory  of  the  dataset,  or 
remap  the  metadata  to  the  thumbnail 
directory. 

8 

View  the  new  KMZ 
data  to  preview  the 
quality  of  the  data. 

Preview  the  color  balance,  cloud  cover, 
feathering,  image  mask  coverage,  and  overall 
quality  of  the  scene. 
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6.6  Elevation  Files 


Requirement 

Result 

Does  the  metadata  match  the  elevation  data  provided? 

Yes/No 

Does  the  data  correlate/overlay  the  image  files  along  the 
coast? 

Yes/No 

Are  all  elevation  files  continuous? 

Yes/No 

6.6.1  Elevation  Sample  Procedure 


Step 

Action 

Procedure  and  Notes 

1 

Repeat  the  common 
tests. 

Common  tests  from  the  General  Geospatial 
Information  and  the  Imagery  section  can  be 
repeated  here. 

2 

Overlay  the  KML  Files 
from  ArcMap  and  the 
KML  files  from  the 
catalog  in  Google 

Earth. 

This  will  provide  verification  that  the  data  on 
the  disk  matches  the  data  in  the  metadata. 
Select  the  newly  created  KML/KMZ  files  and 
open  them  in  Google  Earth. 

3 

Validate  the  continuity 
of  the  Image  files. 

Compare  the  KML  files  from  ArcMap  to  the 

KML  files  from  the  catalog. 

Open  the  KML's  (only)  in  Google  Earth. 

Validate  in  Google  Earth  that  these  data 
blocks  match  by  turning  on  and  off.  Now 
bring  the  KMZ's  from  the  catalog  directory 
into  Google  Earth  and  verify  there  are  no 
holes  in  the  imagery  they  provided. 

6.7  Features 


Requirement 

Result 

Verify  the  point  features  are  geospatially  correct. 

Yes/No 

Verify  the  line  features  are  geospatially  correct. 

Yes/No 

Verify  the  areals  (polygon)  features  are  geospatially  correct. 

Yes/No 

Verify  attribution  schema  used  is  documented  in  DBDD  or 
official  standard. 

Yes/No 

Verify  attribution  code  is  accurate  for  each  feature. 

Yes/No 

Verify  all  key  points  of  interest  listed  in  the  DBDD  were 
provided. 

Yes/No 

If  used,  verify  the  airfield  points  match  the  correct  airfield. 

Yes/No 

20 

WUNCLASSIFIEDW 


NPSI  DPS  2.2 


6.7.1  Features  Sample  Procedure 


Step 

Action 

Procedure  and  Notes 

1 

Import  all  of  the 
shapefiles  into 

ArcMap. 

Search  each  feature  section  (ie.  airbases, 

AOI,  cultural  features,  et.  al.)  in  the  root 
directory  for  shape  files  needing  to  be  brought 
into  ArcMap.  Open  these  files  into  a  newly 
created,  appropriately  named  data  layer. 

2 

Scan  for  any  points 
inconsistently  placed. 

Via  ArcMap. 

3 

Check  to  ensure  there 
are  no  blank  "code"  or 
key  descriptor 
attributes. 

Via  scripts  or  ArcMap. 

4 

Note  and  validate 
attribution  schema. 

Review  schema  and  annotation  via  DBDD 
(custom  schema)  or  one  of  the  standard 
feature  attribution  schemas  (NFDD,  FACC, 
SEDRIS,  etc.) 

5 

Export  map  to  KML. 

In  ArcMap,  use  "Map  to  KML"  to  convert  the 
map  document  to  KML  files.  Select  one  of  the 
shapefile's  data  frames  and  the  output 
directory  for  the  KML  file.  Name  the  KML  file 
appropriately  and  save  with  a  map  output 
scale  of  1. 

Repeat  for  each  Shapefile  data  frame 
(Airbases,  AOI,  Cultural  features) 

6 

Review  each  file  in 
Google  Earth  and  scan 
for  any  outliers. 

In  Google  Earth,  load  the  newly  created 

KMZ's. 

Scan  for  any  points  inconsistently  placed. 

Visually  check  that: 

•  Airfields  match  correct  airfield. 

•  Buildings  are  separated  out. 

•  Codes  are  not  being  repeated  for 
incorrect  features. 

•  Overall  continuity. 

7 

Ensure  the  airfields 
match  the  correct 
airfield  names. 

Visual  check  via  KMZ  or  ArcMap. 

8 

Ensure  the  buildings 
are  separated  out. 

Visual  check  via  KMZ  or  ArcMap. 

9 

Ensure  codes  are  not 
repeated  for  incorrect 
features 

Visual  check  ArcMap 
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6.8  3D  Models 


Requirement 

Result 

Are  the  models  in  a  valid  OpenFlight®  format  of  version  16+? 

Yes/No 

Does  the  model  name  match  or  is  it  recognizably  similar  to  the 
name  in  DBDD? 

Yes/No 

Does  model  snap  shot  in  the  DBDD  match  the  model  itself? 

Yes/No 

Do  the  articulated  parts  in  the  model  and  DBDD  match 
correctly? 

Yes/No 

Are  the  correct  'max  polygons'  listed  in  DBDD? 

Yes/No 

Do  the  lights  match  what  is  listed  in  the  DBDD?  Are  they 
correct? 

Yes/No 

Are  there  any  noticeable  problems  with  geometry  or  textures 
in  any  of  the  LCDs? 

Yes/No 

Are  there  repeated  models  (T/M/S)? 

Yes/No 

Are  there  repeated  models  (with  SAME  textures)? 

Yes/No 

Are  there  repeated  models  (FILENAME)? 

Yes/No 

6.8.1  Moving  Models  Sample  Procedure 


Step 

Action 

Procedure  and  Notes 

1 

Check  if  model  is 
supplied  in 

OpenFlight®  and 
opens  properly  in 
Creator. 

Check  for  a  .fit  and  open  this  file  in  Presagis 
Creator. 

2 

Does  the  model  name 
match  or  is  it 
recognizably  similar  to 
the  name  in  DBDD? 

Open  the  DBDD,  find  the  model  in  the 
document,  and  compare  names. 

3 

Does  the  model 
snapshot  in  the  DBDD 
match  the  model 
itself? 

Open  DBDD,  find  the  model  in  the  document, 
and  compare  geometry/textures. 

4 

Validate  the 
articulated  parts  in  the 
model  and  DBDD. 

Find  the  articulated  parts  in  model  using  the 
DOF  Viewer  in  Creator.  If  articulated  parts 
are  present,  the  viewer  will  come  up  and  list 
the  parts,  otherwise  you  will  get  the  message 
that  says  "No  DOFs  in  Scene." 

5 

Does  polygon  count 
match  the  DBDD? 

Find  the  model  in  the  DBDD  and  find  the 
listed  polygon  count  for  that  model.  Compare 
with  the  polygon  count  in  the  model  as 
reported  by  Creator. 
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6 

Do  lights  match  what 
is  listed  in  the  DBDD? 
Are  they  correct? 

Find  the  model  in  the  DBDD  and  find  the 
listed  required  lights  for  that  model. 

In  Creator,  expand  down  into  the  model's 
hierarchy  to  find  the  light  points.  Open  the 
light  point  attributes  window.  This  should  give 
the  name  of  the  type  of  light  that  will  help 
match  to  what  is  listed  in  the  DBDD. 

7 

Are  there  any 
noticeable  problems 
with  geometry  in  any 
of  the  LODs? 

In  Creator,  flip  through  the  LODs  to  visually 
check  for  missing  geometry. 

8 

Are  there  repeated 
models 

(Type/Model/Series)? 

Flag  item  as  appropriate. 

9 

Are  there  repeated 
models  (with  SAME 
textures)? 

Flag  item  for  possible  deletion. 

10 

Are  there  repeated 
models  (FILENAME)? 

Flag  item  for  possible  deletion. 

11 

Make  note  of  model 
residence  for  easy 
future  locating. 

Just  make  note  here  of  where  the  model 
currently  resides. 

6.9  3D  Airfields 


Requirement 

Result 

Is  there  a  flat  earth  OpenFlight®  version  16+  of  the  airfield 
model? 

Yes/No 

Are  markings  present  and  correct  as  specified  by  the  DBDD? 

Yes/No 

Does  the  airfield  name  match  what  is  listed  in  the  DBDD? 

Yes/No 

Does  the  OpenFlight®  model  have  a  shapefile  associated  with 
it? 

Yes/No 

Do  the  lights  match  what  is  listed  in  the  DBDD?  Are  they 
correct? 

Yes/No 

Are  geometry  and  textures  without  problems  in  all  of  the 

LODs? 

Yes/No 

Does  this  airfield  model  correctly  represent  actual  airfield? 

Yes/No 

6.9.1  3D  Airfields  Sample  Procedure 


step 


Action 


Procedure  and  Notes 
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1 

Is  there  a  Flat  Earth 
version  of  the 
OpenFlight®  airfield 
model? 

Check  for  a  .fit  file  and  open  this  file  in 
Presagis's  Creator.  Open  the  'Fleader 
Attributes'  window  and  select  the  'Projection' 
tab.  Confirm  that  it  reads  'Flat  Earth'  in  the 

Map  Projection  section. 

2 

Are  any  markings 
missing  or  incorrect  as 
specified  by  the 

DBDD? 

In  Creator,  visually  check  the  markings  for 
correctness. 

3 

Does  the  model  name 
match  or  is  it 
recognizably  similar  to 
the  name  in  model 
description  within  the 
DBDD? 

Open  the  DBDD,  find  the  model  in  the 
document  and  compare  names.  You  may  have 
to  search  the  document  thoroughly  to 
conclude. 

4 

Do  lights  match  what 
is  listed  in  the  DBDD? 
Are  they  correct? 

Find  the  model  in  the  DBDD  and  find  the 
listed  required  lights  for  that  model. 

In  Creator,  expand  down  into  the  model's 
hierarchy  to  find  the  light  points.  Open  the 
light  point  attributes  window.  This  should  give 
the  name  of  the  type  of  light  that  will  help 
match  to  what  is  listed  in  the  DBDD. 

5 

Are  there  any 
noticeable  problems 
with  geometry  or 
textures  in  any  of  the 
LCDs? 

In  Creator,  flip  through  the  LODs  to  visually 
check  for  missing  geometry. 

6 

Does  this  airfield 
model  correctly 
represent  the  actual 
airfield? 

Look  up  the  airfield  diagram  for  the  airfield  to 
check  its  validity. 
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Appendix  A  Initial  Data  Production  and  NPSI  Dataset 

Overview 

The  intent  of  the  NPSI  dataset  is  to  provide  database  development  teams  with 
data  that  has  been  prepared  for  simulation  applications  and  can  be  archived  for 
use  on  other  programs.  This  data  will  be  in  "typical"  formats  that  can  be  used 
with  existing  database  generation  tools. 

The  generation  of  the  NPSI  data  includes  the  typical  manipulation  of  source 
data  that  is  involved  in  most  database  projects.  One  primary  difference  is  that 
the  final  versions  of  the  various  data  formats  will  be  collected  and  documented 
for  distribution  to  subsequent  database  efforts. 

A.l  Terrain  Elevation  Data 

Terrain  data  is  normally  in  the  form  of  a  grid  of  elevation  values.  For 
example,  National  Geospatial  Intelligence  Agency  (NGA)  Digital  Terrain  Elevation 
Data  (DTED)  is  a  grid  of  values  within  a  geo-cell.  For  Level  1  DTED,  the  grid 
points  are  spaced  at  three  arc/seconds  of  latitude  and  longitude  (~100  meters). 
This  provides  a  1201  x  1201  grid  of  elevations  for  each  geo-cell.  DTED  Level  2 
has  a  grid  spacing  of  1  arc/second  or  ~30  meters.  There  is  currently  very  little 
Level  2  coverage.  In  general,  the  terrain  data  will  require  modification.  Possible 
actions  include  correcting  any  voids  in  the  data  (these  are  rare  in  current  data) 
and  ensuring  that  edge  conditions  match  at  the  boundaries  with  neighboring  geo¬ 
cells.  It  may  also  be  desirable  to  flatten  areas  for  the  inclusion  of  modeled 
features  such  as  airfields.  Any  thinning  that  is  required  for  providing  a  terrain 
skin  within  the  polygon  limitations  of  the  target  image  generator  are  not  desired 
and  are  not  to  be  included  in  these  refinements.  There  will  be  references  to  the 
final  polygon  skin  in  other  parts  of  the  NPSI  data.  Subsequent  versions  of  the 
database  may  be  able  to  make  use  of  more  of  the  original  terrain  data  either 
because  of  higher  Image  Generator  (IG)  performance  or  because  their  version  of 
the  mission  allows  a  different  polygon  allowance  mix. 

A.2  Feature  Data 

Feature  data  describes  the  cultural  and  natural  features  that  are  on  the 
terrain.  The  most  common  formats  for  feature  data  are  ESRI  Shapefile  format, 
NGA  Digital  Feature  Analysis  Data  (DFAD),  and  Vector  Map  (VMAP).  Flowever, 
DFAD  and  VMAP  are  currently  being  replaced  by  other  formats.  Shapefiles  are 
separated  into  three  types  of  features:  point  features,  linear  features,  and  area 
features.  These  are  described  in  a  data  format  that  includes  locating  points 
(lat./long.),  elevation,  and  feature  identification  codes.  In  the  normal  database 
production  process,  the  feature  data  is  used  in  combination  with  the  terrain 
elevation  data  to  produce  a  terrain  skin  populated  with  features. 
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The  significant  problem  with  feature  data  in  current  simulation  applications 
stems  from  the  lack  of  correlation  between  the  defined  features  and  the  images 
of  those  features  in  satellite  imagery  or  aerial  photography  as  discussed  in 
Section  A. 3.  These  discrepancies  occur  for  a  number  of  reasons.  In  some  cases, 
the  feature  data  approximates  the  real-world  feature  (e.g.,  a  curved  road  is 
represented  as  a  series  of  segments).  In  other  cases,  the  position  of  the  feature 
is  not  accurate  (the  DFAD/VMAP  specification  calls  for  features  to  be  within  50 
feet  of  their  actual  location).  In  cases  of  legacy  data,  the  feature  data  was 
collected  some  time  ago  and  is  no  longer  valid.  Correcting  these  discrepancies 
may  require  a  great  deal  of  adjustment  depending  on  the  database  fidelity 
requirements.  In  general,  these  adjustments  to  the  feature  location,  content,  and 
shape  must  be  done  by  hand.  The  task  does  not  currently  lend  itself  to 
automated  tools.  It  is  important  to  the  NPSI  data  concept  that  any  of  these 
manual  adjustments  to  the  feature  data  be  captured  in  the  refined  version  of  the 
feature  data,  in  an  open  format,  so  that  the  manual  adjustments  are  not 
repeated  in  subsequent  production  efforts.  NEC  attribution  is  to  be  used  as  much 
as  possible  to  identify  feature  data. 

Imagery  Data 

Many  current  simulation  applications  make  use  of  satellite  and/or  aerial 
photography  as  texture  maps  to  represent  the  real-world  terrain  skin  more 
accurately.  The  first  step  is  to  assemble  the  raw  imagery.  Raw  imagery  can  be 
provided  from  government  sources  or  can  be  purchased  from  commercial 
suppliers.  Once  obtained,  the  individual  images  must  be  assembled  into  a  single 
image  mosaic  that  covers  the  database  area.  This  includes  such  complex  tasks  as 
ortho-rectification  and  mosaicing.  Ortho-rectification  is  the  process  of  adjusting 
the  images  so  the  images  appear  to  have  been  photographed  from  directly  above 
and  that  terrain  shapes  and  elevations  are  compensated.  Mosaicing  the  images 
together  into  a  single  image  by  blending  across  edges,  compensating  for 
differences  in  the  images  (time  of  year,  clouds),  and  compensating  for  different 
image  resolutions. 

The  resolution  required  for  the  geo-specific  texture  may  differ  within  the 
database  depending  on  the  mission  parameters.  When  operating  close  to  the 
ground  (e.g.,  takeoff  and  landing,  low-level  navigation),  texel  resolution  of  less 
than  or  equal  to  one  meter  may  be  required.  At  higher  altitudes,  the  texture  map 
resolution  can  be  greater  because  the  texture  level  of  detail  process  (e.g.,  MIP 
mapping)  will  filter  out  the  higher  resolution  versions  of  the  texels.  It  will  be 
beneficial  to  the  NPSI  data  concept  to  process  the  source  imagery  at  the  highest 
resolution  possible  so  that  future  applications  will  have  access  to  this  data  even 
though  the  initial  supplier's  platform  or  mission  may  not  require  or  support  the 
fidelity.  The  technical  and  economic  implications  of  asking  the  supplier  to  provide 
higher  resolution  imagery  than  is  required  will  need  to  be  considered. 

Despite  the  availability  of  a  number  of  tools  for  the  manipulation  of  source 
imagery,  the  task  is  complex  and  tends  to  be  labor  intensive.  It  is  important  to 
both  production  efficiency  and  correlation  that  the  resulting  mosaic  image  (at  the 
highest  practical  resolution)  be  included  in  the  NPSI  data  for  use  on  subsequent 
versions  of  the  database. 
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A.4  Models 

3D  models  are  an  essential  part  of  any  database.  A  feature  model  library  may 
be  used  to  represent  three-dimensional  features.  A  feature  model  library  is  a 
collection  of  conventional  models  of  typical  features  (e.g.  factories,  houses, 
power  plants,  etc.)  that  can  be  positioned  on  the  terrain,  normally  to  represent 
point  features.  In  addition  to  the  feature  model  library,  3D  models  will  also  be 
used  to  represent  specific  features  in  the  database.  These  include  high  detail 
areas  such  as  airfields  and  targets,  unique  features  or  landmarks  used  for 
navigation  purposes,  and  dynamic  target  models  such  as  aircraft  and  vehicles. 
For  any  given  database  production  effort,  the  3D  models  will  be  a  combination  of 
newly  developed  features  (e.g.,  the  home  airfield)  and  models  adapted  from 
previous  programs  (e.g.,  target  aircraft).  In  adapting  previous  models,  it  may  be 
necessary  to  make  adjustments  to  account  for  the  overall  visual  system 
performance.  This  includes  the  resolution  of  the  display  system  and  the 
performance  of  the  IG. 

In  addition  to  the  basic  models,  it  may  also  be  necessary  to  include  several 
alternate  versions  of  the  modeled  feature.  These  typically  include  damaged  and 
destroyed  versions  that  can  be  selected  when  appropriate.  Other  model 
characteristics  may  include  alternate  polygons  or  textures  for  sensor  effects 
(e.g.,  hot  spots)  that  are  activated  when  appropriate  to  the  mission  scenario. 
Each  model  may  also  include  several  levels  of  detail.  These  are  intended  to 
represent  the  feature  with  fewer  and  fewer  polygons  at  greater  distances.  Level 
of  detail  and  scaling  is  sometimes  used  to  make  the  feature  more  visible  at  long 
range  (e.g.  by  increasing  the  contrast  with  the  background). 

Both  the  construction  of  new  models  and  the  adaptation  of  legacy  models  are 
primarily  manual  tasks.  It  is  again  important  that  these  value  added  efforts  be 
captured  in  the  NPSI  data  in  an  open  format,  so  that  these  manual  tasks  are  not 
repeated  in  subsequent  production  efforts.  It  may  be  necessary  to  make 
adjustments  in  order  for  the  models  to  be  optimized  for  alternate  image 
generators  and/or  platform  missions.  The  format  of  the  3D  models  and 
accompanying  documentation  are  designed  to  facilitate  this  optimization. 
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Appendix  B  Run-time  Database  Production  Concepts 

This  effort  includes  the  typical  production  process  that  would  be  employed  on 
any  large  database  effort.  The  native  database  tools  for  the  initial  target  IG  will 
process  the  corrected  and  correlated  source  data  discussed  in  the  previous 
sections.  The  design  factors  that  are  incorporated  into  the  database  are  based  on 
the  performance  of  the  IG  (e.g.,  number  of  polygons,  amount  of  texture,  texture 
resolution,  etc.)  and  the  mission(s)  of  the  individual  platforms  (e.g.,  low  level 
navigation).  Many  aspects  of  the  database  that  are  implemented  in  this  step  are 
eventually  incorporated  into  the  final  NPSI  data. 

B.l  Terrain  Generation 

The  terrain  elevation  and  terrain  feature  data  are  combined  to  generate  the 
terrain  skin  and  associated  features.  In  most  cases,  the  IG  performance  requires 
that  both  the  terrain  and  feature  data  be  culled  to  limit  the  number  of  polygons 
to  the  amount  that  can  be  rendered  at  the  required  update  rate.  The  resulting 
terrain  skin  polygons  take  the  form  of  either  a  regular  mesh  or  a  triangulated 
irregular  network  (TIN)  depending  on  the  IG  architecture.  The  levels  of  detail 
contained  in  the  terrain  structure,  and  the  method  of  switching  from  one  level  to 
the  next,  depends  on  the  IG  performance  and  features.  A  significant  part  of  the 
terrain  design  includes  the  degree  to  which  the  features  are  allowed  to  influence 
the  terrain  skin.  Forcing  the  terrain  to  incorporate  river  valleys,  road  geometry, 
complex  coastlines,  and  other  similar  features  provides  a  much  more  realistic 
looking  database  at  the  expense  of  a  large  number  of  polygons  that  are  not 
available  for  other  features  such  as  3D  models. 

B.2  Polygonal  Feature 

Changes  made  to  the  terrain  to  accommodate  features  are  captured  to  the 
maximum  extent  possible  when  elevation  data  is  exported  to  the  DTED  or 
GeoTIFF  format  used  to  represent  the  final  NPSI  data.  Several  processes  are 
used  to  generate  a  polygonal  representation  of  feature  data.  Polygons  for  some 
features  are  constructed  by  third  party  tools  as  part  of  the  terrain  skinning 
process.  These  include  linear  features  such  as  roads  that  are  defined  as  a  series 
of  points  that  mark  the  centerline  of  the  road.  The  codes  with  the  road  lineal 
indicate  the  type  of  road  that  is  intended  (e.g.,  width,  number  of  lanes,  etc.). 
Tools  are  used  to  create  the  required  polygons  in  the  correct  positions  along  the 
terrain  surface.  As  part  of  the  polygon  generation,  appropriate  texture  maps  are 
assigned  to  the  road  surface.  Depending  on  the  application  for  the  database,  the 
tools  to  incorporate  additional  characteristics  into  the  road  in  order  to  make  it 
trafficable  (as  opposed  to  a  simple  road  that  is  only  viewed  from  an  aircraft)  may 
also  be  necessary.  Adding  roadside  shoulders  and  berms  and/or  cutting  the  road 
into  hillsides  require  more  polygons  than  the  simple  2D  road. 

Point  features  may  be  converted  to  polygonal  representations  by  referencing 
a  feature  model  library.  The  models  may  be  selected  randomly  so  that  not  all  of 
the  houses  or  factories  are  identical.  It  is  sometimes  necessary  to  customize  the 
feature  model  library  for  the  part  of  the  world  represented  by  the  database.  A 
village  or  church  features  identified  by  the  DFAD/VMAP  point  feature  may  have  a 
different  appearance  depending  on  the  local  culture. 
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Some  point  features  require  that  a  model  be  adjusted  to  the  terrain.  A  good 
example  is  a  bridge.  Typically,  the  feature  model  library  includes  a  bridge  section 
or  prototype.  The  tools  then  adapt  the  bridge  model  to  the  specific  application. 
This  includes  rotating  the  bridge  to  align  with  the  road  or  railroad  lineal  that  the 
bridge  supports,  and  "stretching"  the  bridge  to  meet  the  ends  of  the  road  or 
railroad.  Stretching  may  involve  actually  changing  the  geometry  of  the  model  or 
repeating  the  bridge  segment  until  it  is  long  enough  to  cover  the  gap  between 
the  lineal  ends.  Changes  to  the  feature  data  are  to  be  captured  to  the  maximum 
extent  possible  (e.g.,  attributes,  coordinate  changes)  before  exporting  to  the  final 
NPSI  shapefile(s). 

B.3  Imagery 

Satellite  and/or  aerial  imagery  for  the  entire  database  area  is  processed  into 
texture  maps.  This  may  take  the  form  of  a  single  large  map  or  be  broken  up  into 
small  sections  that  match  the  terrain  tiles. 

B.4  3D  Models 

Due  to  the  nature  of  3D  models  and  their  open  formats,  the  separation 
between  the  source  version  of  the  model  included  in  the  NPSI  data  and  the 
application  specific  version  included  in  the  database  is  less  clear.  All  aspects  of 
any  new  models  generated  to  meet  specific  requirements  (e.g.,  the  home 
airfield)  are  included  in  the  NPSI  data.  Exceptions  may  occur  where  changes  are 
made  (particularly  deletions)  in  support  of  specific  platform  features  that  are  not 
likely  to  be  of  use  elsewhere.  These  might  include  the  addition  of  special 
polygons  or  versions  of  the  model  to  support  specific  sensor  effects.  The  original 
version  of  the  model  may  be  more  useful  as  a  starting  point  for  follow  on 
applications  and  platforms.  These  choices  are  examined  on  a  case-by-case  basis. 

B.5  3D  Moving  Models 

3D  moving  models  are  dynamic  models  that  may  include  one  or  more 
animations  as  part  of  the  model.  The  NPSI  data  for  3D  moving  models 
incorporate  all  data  that  may  be  useful  on  other  platforms,  but  the  run-time  3D 
moving  model  may  include  information  specific  to  only  one  platform. 

B.6  Metadata 

Metadata  is  data  used  to  describe  data  including  information  such  as  source, 
projections,  locations,  licensing  information,  and  other  descriptive  data  specific  to 
each  data  element.  NAVAIR  has  developed  a  metadata  schema  in  XML,  which  is 
defined  by  the  NAVAIR  Portable  Source  Initiative  Standard  for  Reusable  Source 
Dataset  Metadata  V2.4  document. 
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B.7  Database  Working  Groups 

other  than  the  need  to  capture  useful  refined  source  data,  it  is  assumed  that 
the  database  production  process  will  be  typical  of  any  government  procurement. 
This  typically  includes  a  number  of  Database  Working  Group  meetings  where  the 
progress  of  the  production  is  reviewed  with  representatives  from  the  user 
community.  These  reviews  provide  the  opportunity  for  the  users  to  see  how 
various  features  and  terrain  areas  are  represented.  These  reviews  also  provide  an 
opportunity  for  the  database  design  team  to  gather  useful  inputs  from  the  users 
as  to  the  locations  and/or  appearance  of  significant  features.  At  the  early  review 
meetings,  it  is  common  to  demonstrate  representative  features  and  terrain  areas 
for  approval.  At  subsequent  meetings,  larger  and  larger  sections  of  the  database 
are  demonstrated  until  the  final  product  is  available.  The  database  should  be 
viewed  with  the  display  device  that  is  used  in  the  final  application  and  when 
possible  viewed  in  the  simulator  device. 
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Appendix  C  Recommended  OpenFlight©  Airport  Hierarchy 

The  goal  of  NPSI  for  the  3D  Airfield  Models  is  to  create  an  interchange  format  that  allows  for 
automated  restructuring  of  the  data.  In  order  to  achieve  this  goal,  a  standard  format  must  be  agreed  upon 
throughout  industry.  To  initiate  discussion  on  this  topic,  an  initial  structure  has  been  compiled.  All 
comments  are  welcome. 


Notes  and  Modeling  Expectations: 

All  polygon  faces  and  vertexes  should  face  the  same  normal  direction  to  avoid  undesired  backfacing. 

No  concurrent  vertices  are  desired. 

No  non-planar  faces  are  desired. 

No  concave  faces  are  desired. 

Footprints  should  exist  for  each  LOD  to  match  that  LCD's  geometry. 

Object  nodes  should  contain  no  more  than  1024  polygons.  If  there  are  >1024  polygons  residing  under 
an  object  node,  multiple  object  nodes  should  be  created.  (NOT  REQUIRED) 

The  intent  of  this  recommended  hierarchy  is  to  simplify  or  automate  the  process  of  tailoring  the  model 
to  a  particular  run-time.  As  such,  while  consistency  is  important,  this  should  not  drive  a  technical 
approach  to  modeling.  However,  if  an  implemented  hierarchy  deviates  from  this  guideline,  it  should  be 
consistent,  documented,  and  lend  itself  to  the  intent  of  simplifying  the  aggregation  and  disaggregation  of 
elements. 
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C.l  Individual  Building  File  Hierarchy  Structure 


Figure  2  OpenFlight®  building  hierarchy  example. 
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.2  Runway  File  Hierarchy  Structure 

Comment  field  at  the  root  level  (db)  should  include  the  year  of  the  rendered  airport. 
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C.3  Airport  Lights  File  Hierarchy  Structure 


Figure  4  OpenFlight®  airport  lights  hierarchy  example. 
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Figure  5  Airport  light  palette  example  with  descriptive  naming  convention. 
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C.4  Foot-To-Go  Hierarchy  Structure 


Figure  6  OpenFlight®  foot-to-go  hierarchy  example. 
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C.5  Master  File  Preview  Hierarchy  Structure 


This  file  is  to  be  used  for  rapid  viewing  of  the  Airfield  and  is  not  anticipated  to  be  run-time  formatted. 
Nested  External  references  can  yield  poor  performance.  This  file  is  not  required. 


Figure  7  OpenFlight®  master  file  hierarchy  example. 
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Appendix  D  CDB  v  2.1  Light  Point  Excerpt 

This  section  shows  the  current  format  for  light  points  "Airfield  Extract"  as  noted 
from  the  Common  Database  (CDB)  Specification  for  USSOCOM,  Report  N61339-01- 
D-0725/0003  -  G005. 


It  is  desired  that  the  standard  names  for  the  Light  Point  Palette  for  both 
appearance  and  animation  are  representative  of  the  lists  within  Appendix  D.  The 
Light  point  palette  is  a  searchable  entry  within  the  model  and  with  common  naming; 
a  more  interchangeable  light  point  setup  can  be  used. 


See  next  pages  for  the  excerpt. 
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Light  Hierarchy 

Light 

Code 

Description 

Intensity 

[normalized) 

Color 

[normalized 

RGB) 

Directionality 

(type) 

Wldth_Hor 

(degrees) 

Width_Vert 

(degrees) 

lntenslty_Res 

[normalized) 

Frequency 

(Hz) 

Duty_Cycle 

[normalized) 

1  Airport Lighting 

274 

Generic  Airport  Lighting 

0.9 

1  1 1  1 1 

Omni 

_ 

_ 

_ 

Apron 

275 

Generic  Apron  light 

0.9 

1  1 1  1 1 

Omni 

... 

Entrance Light 

276 

Apron  entrance  light  from  runway  or  taxiway 

0.9 

1  1 1  1 1 

Omni 

... 

Flood Light 

277 

Flood  light  to  illuminated  the  Apron 

0.9 

1  1 1  1 1 

Omni 

_ 

_ 

_ 

_ 

_ 

Beacon 

278 

Generic  Beacon  light 

0.9 

1  1 1  1 1 

Omni 

_ 

_ 

0.33 

0.33 

ID 

Beacon  Light 

279 

Identification  Beacon  light 

0.9 

1  1 1  1 1 

Omni 

0.33 

0.33 

White. Rotating  2sec  Light 

280 

White  2  sec  interval  Rotating  Beacon 

0.9 

1  1 1  1 1 

Omni 

0.5 

0.33 

White Rotatlng 3sec Light 

281 

White  3  sec  interval  Rotating  Beacon 

0.9 

1  1 1  1 1 

Omni 

_ 

_ 

_ 

0.33 

0.33 

White Rotating 5sec Light 

282 

White  5  sec  interval  Rotating  Beacon 

0.9 

1  1 1  1 1 

Omni 

_ 

_ 

0.2 

0.33 

Green  Rotating  2sec Light 

283 

Green  2  sec  interval  Rotating  Beacon 

0.9 

0  1  1  1  0 

Omni 

0.5 

0.33 

Green Rotating 3sec Light 

284 

Green  3  sec  interval  Rotating  Beacon 

0.9 

0  1  1  1  0 

Omni 

0.33 

0.33 

Green Rotating 5sec Light 

285 

Green  5  sec  interval  Rotating  Beacon 

0.9 

0  1  1  1  0 

Omni 

_ 

_ 

0.2 

0.33 

White Flashing 2sec Light 

286 

White  2  sec  interval  Flashing  Beacon 

0.9 

1 1 1 1 1 

Omni 

_ 

_ 

0.5 

0.33 

White Flashing  3sec  Light 

287 

White  3  sec  interval  Flashing  Beacon 

0.9 

1 1 1 1 1 

Omni 

0.33 

0.33 

White Flashing 5sec Light 

288 

White  5  sec  interval  Flashing  Beacon 

0.9 

1 1 1 1 1 

Omni 

0.2 

0.33 

Green Flashing 2sec Light 

289 

Green  2  sec  interval  Flashing  Beacon 

0.9 

0  1  1  1  0 

Omni 

_ 

_ 

0.5 

0.33 

Green Flashing 3sec Light 

290 

Green  3  sec  interval  Flashing  Beacon 

0.9 

0  1  1  1  0 

Omni 

_ 

_ 

0.33 

0.33 

Green  Flashing  5sec Light 

291 

Green  5  sec  interval  Flashing  Beacon 

0.9 

0  1  1  1  0 

Omni 

0.2 

0.33 

DockingSytem 

292 

Generic  docking  system  light 

0.9 

1  1  0.6  1  0 

Omni 

... 

Amber Light 

293 

Amber  Docking  System  light 

0.9 

1  1  0.6  1  0 

Omni 

_ 

_ 

_ 

_ 

_ 

Green Light 

294 

Green  Docking  System  light 

0.9 

0  1  1  1  0 

Omni 

_ 

_ 

_ 

Red  Light 

295 

Red  Docking  System  light 

0.9 

1  |0|0 

Omni 

... 

Obstruction 

296 

Red  light  indicating  the  presence  of  an  object  which  is 
dangerous  to  an  aircraft  in  flight. 

0.85 

1  |0|0 

Omni 

0.5 

0.33 

Flashing Light 

297 

Red  Obstruction  flashing  light 

0.85 

1  |0|0 

Omni 

_ 

_ 

0.5 

0.33 

HiJntensity Light 

298 

Red  Hi-Intensity  obstruction  light 

0.9 

1  |0|0 

Omni 

_ 

_ 

0.5 

0.33 

Runway 

299 

Generic  Runway  lights 

0.9 

1 1 1 1 1 

Omni 

... 

Approach System 

300 

Generic  Airport  Approach  Lighting  Systems 

0.9 

1 1 1 1 1 

Dir 

75 

75 

... 

Barrette 

301 

Barrette  light 

0.9 

1 1 1 1 1 

Dir 

75 

75 

_ 

_ 

Red_Light 

302 

Red  barrette  light 

0.9 

1  |0|0 

Dir 

75 

75 

_ 

_ 

White_Light 

303 

White  barrette  light 

0.9 

1 1 1 1 1 

Dir 

75 

75 

... 

Circling Guidance Light 

304 

Circling  Guidance  Light  which  helps  on  a  circling  approach 

0.9 

1 1 1 1 1 

Dir 

75 

75 

... 

Landing Marking Light 

305 

Marking  Lights  that  illuminate  any  markings  that  need  to  be 
visible  on  the  runway  in  low  visibility 

0.9 

1 1 1 1 1 

Omni 

_ 

_ 

_ 

Lead-in Light 

306 

LDIN  -  lead'in  light  system  lights 

0.9 

1 1 1 1 1 

Dir 

50 

110 

_ 

_ 

Optical Landing  System 

307 

Optical  landing  system  lights 

0.9 

1 1 1 1 1 

Omni 

... 

High lntensity Light 

308 

High  intensity  approach  light 

0.9 

1 1 1 1 1 

Dir 

75 

75 

... 

LowJntensity Light 

309 

Low  intensity  approach  light 

0.85 

1 1 1 1 1 

Dir 

75 

75 

_ 

_ 

_ 

ODAL Light 

310 

Omni  directional  approach  light 

0.9 

1 1 1 1 1 

Omni 

_ 

_ 

_ 
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Light 

Code 

Description 

Intensity 

(normalized) 

Color 

(normalized 

RGB) 

Directionality 

(type) 

Width_Hor 

(degrees) 

Width_Vert 

(degrees) 

lntensity_Res 

(normalized) 

Frequency 

(Hz) 

Duty_Cycle 

(normalized) 

PAPI 

311 

Generic  Precision  approach  path  indicator.  Provides  visual 
glide  slope  indication  using  a  single  row  of  tw/o  or  four  light 

0.95 

1  1 1  1 1 

Dir 

75 

10 

_ 

_ 

APAPI  Close  Light 

312 

Abbreviated  Precision  Approach  Path  Indicator  closest  to 
runway 

0.95 

1  1 1  1 1 

Dir 

75 

10 

APAPI Far Light 

313 

Abbreviated  Precision  Approach  Path  Indicator  farthest  to 
runway 

0.95 

1  1 1  1 1 

Dir 

75 

10 

TypeA Light 

314 

PAPI  A  {farthest  from  runway) 

0.95 

1  1 1  1 1 

Dir 

75 

10 

_ 

_ 

_ 

TypeB Lighl 

315 

PAPI  B  (3rd  from  runway) 

0.95 

1  1 1  1 1 

Dir 

75 

10 

_ 

_ 

TypeC  Light 

316 

PAPI  C  (2rd  from  runway) 

0.95 

1  1 1  1 1 

Dir 

75 

10 

TypeD Light 

317 

PAPI  D  (Closest  from  runway) 

0.95 

1  1 1  1 1 

Dir 

75 

10 

RAIL Light 

318 

Runway  alignment  indicator  lights 

0.9 

1  1 1  1 1 

Dir 

75 

75 

_ 

_ 

REIL Light 

319 

Runway  End  Identifier  Lights 

0.95 

1  1 1  1 1 

Dir 

75 

75 

_ 

2 

0.33 

SFL 

320 

Generic  Sequence  Flashing  Lights 

0.9 

1  1 1  1 1 

Dir 

75 

75 

2 

0.1 

CAT-1 

321 

Approach  Lighting  System  with  sequenced  flashing 

0.9 

1  1 1  1 1 

Dir 

75 

75 

2 

0.1 

CAT-1 1 

322 

Approach  Lighting  System  with  sequenced  flashing 

0.9 

1  1 1  1 1 

Dir 

75 

75 

_ 

2 

0.1 

CALVERT-I 

323 

Approach  Lighting  System  with  sequenced  flashing 

0.9 

1  1 1  1 1 

Dir 

75 

75 

_ 

2 

0.1 

CALVERT-II 

324 

Approach  Lighting  System  with  sequenced  flashing 

0.9 

1  1 1  1 1 

Dir 

75 

75 

2 

0.1 

ALSF-1 

325 

Approach  Lighting  System  with  sequenced  flashing 

0.9 

1  1 1  1 1 

Dir 

75 

75 

2 

0.1 

ALSF-II 

326 

Approach  Lighting  System  with  sequenced  flashing 

0.9 

1  1 1  1 1 

Dir 

75 

75 

_ 

2 

0.1 

SSALF 

327 

Approach  Lighting  System  with  sequenced  flashing 

0.9 

1  1 1  1 1 

Dir 

75 

75 

_ 

2 

0.1 

SSALR 

328 

Approach  Lighting  System  with  sequenced  flashing 

0.9 

1  1 1  1 1 

Dir 

75 

75 

2 

0.1 

MALSF 

329 

Approach  Lighting  System  with  sequenced  flashing 

0.9 

1  1 1  1 1 

Dir 

75 

75 

2 

0.1 

MALSR 

330 

Approach  Lighting  System  with  sequenced  flashing 

0.9 

1  1 1  1 1 

Dir 

75 

75 

_ 

2 

0.1 

VASI 

331 

Generic  Visual  Approach  Slope  Indicator  System  (VASI) 

0.9 

1  1 1  1 1 

Dir 

75 

10 

_ 

_ 

2Bar 

332 

2  Bar  Component  VASI 

0.9 

1  1 1  1 1 

Dir 

75 

10 

First Light 

333 

2-Bar  VASIS  (1st  bar  closest  to  threshold) 

0.9 

1  1 1  1 1 

Dir 

75 

10 

Second Light 

334 

2-Bar  VASIS  (2nd  bar  farthest  from  threshold) 

0.9 

1  1 1  1 1 

Dir 

75 

10 

_ 

_ 

3Bar 

335 

3  Bar  component  VASI 

0.9 

1  1 1  1 1 

Dir 

75 

10 

_ 

_ 

_ 

First  Light 

336 

3-Bar  VASIS  (1st  bar  closest  to  threshold) 

0.9 

1  1 1  1 1 

Dir 

75 

10 

Second Light 

337 

3-Bar  VASIS  (2nd  bar,  In  between  1st  and  3rd) 

0.9 

1  1 1  1 1 

Dir 

75 

10 

Third Light 

338 

3-Bar  VASIS  (3rd  bar  farthest  from  threshold) 

0.9 

1  1 1  1 1 

Dir 

75 

10 

_ 

_ 

LCVASLLight 

339 

Low-cost  VASI  light 

0.9 

1  1 1  1 1 

Dir 

75 

10 

_ 

_ 

TypeP Light 

340 

PVASI  pulsating  light 

0.9 

1  1 1  1 1 

Dir 

75 

10 
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Light 

Code 

Description 

Intensity 

(normalized) 

Color 

(normalized 

RGB) 

Directionality 

(type) 

Wldth_Hor 

(degrees) 

Width_Vert 

(degrees) 

lntenslty_Res 

(normalized) 

Frequency 

(Hz) 

Duty_Cycle 

(normalized) 

1  Type! 

341 

Generic  T  Shaped  VASI  (T-VASIS) 

0.9 

1  1 1  1 1 

Dir 

75 

10 

_ 

_ 

Fly-down Light 

342 

Fly  Down  lights 

0.9 

1  1 1  1 1 

Dir 

75 

7 

Wing Bar Light 

343 

T-VASiS  wing  bar  light 

0.9 

1  1 1  1 1 

Dir 

75 

10 

2.50 Degree 

344 

2.50  degree  T-VASi 

0.9 

1  1 1  1 1 

Dir 

75 

2.5 

_ 

_ 

_ 

FIy*Up1 Light 

345 

T-VASiS  Fly-up  1  (closest  to  Wing  Bar)  for  2.5  degree  Glide 
siope 

0.9 

1  1 1  1 1 

Dir 

75 

2.5 

_ 

_ 

Fly-Up2  Light 

346 

T-VASiS  Fly-up  2  (closest  to  Wing  Bar)  for  2.5  degree  Glide 
siope 

0.9 

1  1 1  1 1 

Dir 

75 

2.4166 

FIy-Up3 Light 

347 

T-VASiS  Fly-up  3  (farthest  to  Wing  Bar)  for  2.5  degree  Glide 
siope 

0.9 

1  1 1  1 1 

Dir 

75 

2.3334 

2.75 Degree 

348 

2.75  degree  T-VASi 

0.9 

1  1 1  1 1 

Dir 

75 

2.75 

_ 

_ 

Fly*Up1 Light 

349 

T-VASiS  Fly-up  1  (closest  to  Wing  Bar)  for  2.7  degree  Glide 
siope 

0.9 

1  1 1  1 1 

Dir 

75 

2.75 

_ 

_ 

Fly-Up2 Light 

350 

T-VASiS  Fly-up  2  (closest  to  Wing  Bar)  for  2.7  degree  Glide 
siope 

0.9 

1  1 1  1 1 

Dir 

75 

2.6666 

Fly-Up3 Light 

351 

T-VASiS  Fly-up  3  (farthest  to  Wing  Bar)  for  2.7  degree  Glide 
siope 

0.9 

1  1 1  1 1 

Dir 

75 

2.5834 

3.00 Degree 

352 

3.00  degree  T-VASi 

0.9 

1  1 1  1 1 

Dir 

75 

3 

_ 

_ 

_ 

Fly-Up1 Light 

353 

T-VASiS  Fly-up  1  (closest  to  Wing  Bar)  for  3.0  degree  Glide 
siope 

0.9 

1  1 1  1 1 

Dir 

75 

3 

_ 

_ 

Fly-Up2  Light 

354 

T-VASiS  Fly-up  2  (closest  to  Wing  Bar)  for  3.0  degree  Glide 
siope 

0.9 

1  1 1  1 1 

Dir 

75 

2.9166 

Fly-Up3 Light 

355 

T-VASiS  Fly-up  3  (farthest  to  Wing  Bar)  for  3.0  degree  Glide 
siope 

0.9 

1  1 1  1 1 

Dir 

75 

2.8334 

3.25 Degree 

356 

3.25  degree  T-VASi 

0.9 

1  1 1  1 1 

Dir 

75 

3.25 

_ 

_ 

Fly*Up1 Light 

357 

T-VASiS  Fly-up  1  (closest  to  Wing  Bar)  for  3.25  degree  Glide 
siope 

0.9 

1  1 1  1 1 

Dir 

75 

3.25 

_ 

_ 

Fly-Up2  Light 

358 

T-VASiS  Fly-up  2  (closest  to  Wing  Bar)  for  3.25  degree  Glide 
slope 

0.9 

1  1 1  1 1 

Dir 

75 

3.1666 

Fly-Up3 Light 

359 

T-VASIS  Fly-up  3  (farthest  to  Wing  Bar)  for  3.25  degree  Glide 
slope 

0.9 

1  1 1  1 1 

Dir 

75 

3.0834 

3.50 Degree 

360 

3.5  degree  T-VASI 

0.9 

1  1 1  1 1 

Dir 

75 

3.5 

_ 

_ 

_ 

Fly*Up1 Light 

361 

T-VASIS  Fly-up  1  (closest  to  Wing  Bar)  for  3.5  degree  Glide 
slope 

0.9 

1  1 1  1 1 

Dir 

75 

3.5 

_ 

_ 

Fly-Up2  Light 

362 

T-VASIS  Fly-up  2  (closest  to  Wing  Bar)  for  3.5  degree  Glide 
slope 

0.9 

1  1 1  1 1 

Dir 

75 

3.4166 

Fly-Up3 Light 

363 

T-VASIS  Fly-up  3  (farthest  to  Wing  Bar)  for  3.5  degree  Glide 
slope 

0.9 

1  1 1  1 1 

Dir 

75 

3.3334 

3.75 Degree 

364 

3.75  degree  T-VASI 

0.9 

1  1 1  1 1 

Dir 

75 

3.75 

_ 

_ 

Fly*Up1 Light 

365 

T-VASIS  Fly-up  1  (closest  to  Wing  Bar)  for  3.75  degree  Glide 
slope 

0.9 

1  1 1  1 1 

Dir 

75 

3.75 

_ 

_ 

_ 

Fly-Up2 Light 

366 

T-VASIS  Fly-up  2  (closest  to  Wing  Bar)  for  3.75  degree  Glide 
slope 

0.9 

1  1 1  1 1 

Dir 

75 

3.6666 

Fly-Up3 Light 

367 

T-VASIS  Fly-up  3  (farthest  to  Wing  Bar)  for  3.75  degree  Glide 
slope 

0.9 

1  1 1  1 1 

Dir 

75 

3.5834 

4.00 Degree 

368 

4.00  degree  T-VASI 

0.9 

1  1 1  1 1 

Dir 

75 

4 

_ 

_ 

Fiy*Up1 Light 

369 

T-VASIS  Fly-up  1  (closest  to  Wing  Bar)  for  4.0  degree  Glide 
slope 

0.9 

1  1 1  1 1 

Dir 

75 

4 

_ 

_ 

Fly-Up2 Light 

370 

T-VASIS  Fly-up  2  (closest  to  Wing  Bar)  for  4.0  degree  Glide 
slope 

0.9 

1  1 1  1 1 

Dir 

75 

3.9166 

Fly-Up3 Light 

371 

T-VASIS  Fly-up  3  (farthest  to  Wing  Bar)  for  4.0  degree  Glide 
slope 

0.9 

1  1 1  1 1 

Dir 

75 

3.8334 
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Light  Hierarchy 

Light 

Code 

Description 

Intensity 

[normalized) 

Color 

[normalized 

RGB) 

Directionality 

(type) 

Wldth_Hor 

[degrees) 

Width_Vert 

[degrees) 

lntenslty_Res 

[normalized) 

Frequency 

(Hz) 

Duty_Cycle 

[normalized) 

Centerline 

372 

Generic  Centerline  runway  light 

0.9 

1  1 1  1 1 

Bi-Dir 

75 

75 

_ 

_ 

Red  Light 

373 

Unidirectional  Red  centerline  light 

0.9 

1  |0|0 

Dir 

75 

75 

White Light 

374 

Unidirectional  White  centerline  light 

0.9 

1 1 1 1 1 

Dir 

75 

75 

White White Light 

375 

Bidirectional  White  centerline  light 

0.9 

1 1 1 1 1 

Bi-Dir 

75 

75 

_ 

_ 

White Red Light 

376 

White-Red  centerline  light 

0.9 

1 1 1 1 1 

Bi-Dir 

75 

75 

_ 

_ 

Edge 

377 

Generic  Runway  Edge  lights 

0.9 

1 1 1 1 1 

Bi-Dir 

180 

180 

White Light 

378 

Unidirectional  White  Edge  light 

0.9 

1 1 1 1 1 

Dir 

180 

180 

Amber Light 

379 

Unidirectional  Amber  Edge  light 

0.9 

1  1  0.6  1  0 

Dir 

180 

180 

_ 

_ 

Red Light 

380 

Unidirectional  Red  Edge  light 

0.9 

1  |0|0 

Dir 

180 

180 

_ 

_ 

Biue Light 

381 

Unidirectional  Blue  Edge  light 

0.9 

0  |0|  1 

Dir 

180 

180 

White Whlte Llght 

382 

Bidirectional  White  Edge  light 

0.9 

1  1  1  1  1 

Bi-Dir 

180 

180 

White Amber Light 

383 

White-Amber  Edge  light 

0.9 

1  1  1  1  1 

Bi-Dir 

180 

180 

_ 

_ 

_ 

White Red Light 

384 

White-Red  Edge  light 

0.9 

1  1  1  1  1 

Bi-Dir 

180 

180 

_ 

_ 

White  Biue  Light 

385 

White-Blue  Edge  light 

0.9 

1  1  1  1  1 

Bi-Dir 

180 

180 

Amber Amber Light 

386 

Bidirectional  Amber  Edge  light 

0.9 

1  1  0.6  1  0 

Bi-Dir 

180 

180 

Amber Red Light 

387 

Amber-Red  Edge  light 

0.9 

1  1  0.6  1  0 

Bi-Dir 

180 

180 

_ 

_ 

Amber Biue Light 

388 

Amber-Blue  Edge  light 

0.9 

1  1  0.6  1  0 

Bi-Dir 

180 

180 

_ 

_ 

Biue  Red  Light 

389 

Blue-Red  Edge  light 

0.9 

0|0|1 

Bi-Dir 

180 

180 

Red Red Light 

390 

Bidirectional  Red  Edge  light 

0.9 

1  |0|0 

Bi-Dir 

180 

180 

Btue BIue Light 

391 

Bidirectional  Blue  Edge  light 

0.9 

0|0|1 

Bi-Dir 

180 

180 

_ 

_ 

End Wing Light 

392 

Runway  End  Wing  lights 

0.9 

1  |0|0 

Dir 

180 

180 

_ 

_ 

End  Light 

393 

Runway  End  lights 

0.9 

1  |0|0 

Dir 

180 

180 

Flood Light 

394 

Runway  flood  lights 

0.9 

1I1I1 

Omni 

Overrun 

395 

Light  which  indicated  runway  over  run  area 

0.9 

1  I  0.6  I  0 

Dir 

150 

90 

_ 

_ 

Amber Light 

396 

Amber  overrun  light 

0.9 

1  1  0.6  1  0 

Dir 

150 

90 

_ 

_ 

_ 

Biue Light 

397 

Blue  overrun  light 

0.9 

0|0|1 

Dir 

150 

90 

Red Light 

398 

Red  overrun  light 

0.9 

1  |0|0 

Dir 

150 

90 

ThreshoId Wing Light 

399 

Threshold  wing  lights 

0.9 

0|1|0 

Dir 

180 

180 

_ 

_ 

Threshold Light 

400 

Runway  threshold  lights:  used  to  identify  the  landing  threshold 
of  the  runway 

0.9 

0|1|0 

Dir 

180 

180 

_ 

_ 

Touchdown  Zone  Light 

401 

Touchdown  Zone  lights:  used  to  identify  the  appropriate 
landing  area  on  the  runway  after  the  threshold 

0.9 

1I1I1 

Dir 

180 

180 

LAHSO Ught 

402 

Land  and  hold  Short  Operations  light:  runway  intersecting  stop 
lights 

0.9 

1  I  0.6  I  0 

Omni 
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Light  Hierarchy 

Light 

Code 

Description 

Intensity 

[normalized) 

Color 

[normalized 

RGB) 

Directionality 

(type) 

Width_Hor 

(degrees) 

Width_Vert 

(degrees) 

lntenslty_Res 

[normalized) 

Frequency 

(Hz) 

Duty_Cycle 

[normalized) 

Taxiway 

403 

Generic  Airport  Taxiway  lights 

0.9 

0|0|1 

Omni 

_ 

_ 

_ 

Apron  Entrance  Light 

404 

Apron  Entrance  light  which  indication  area  where  taxi  enters 
apron  area 

0.9 

0|0|1 

Omni 

CAT-iii HoId Bar Light 

405 

Category  III  Hold  bar  light 

0.9 

0|1|0 

Dir 

180 

180 

Centerline 

406 

Generic  Centerline  Taxiway  lights 

0.9 

OHIO 

Dir 

90 

110 

_ 

_ 

Aiigned Light 

407 

Alighted  light  for  a  straight  sequence  of  a  taxiway 

0.9 

0|1|0 

Dir 

90 

110 

_ 

_ 

Curved  Light 

408 

Curved  lights  for  a  curved  sequence  of  a  taxiway 

0.9 

0|1|0 

Dir 

50 

110 

Edge Light 

409 

Taxiway  edge  lights 

0.9 

0|0|1 

Omni 

High-speed 

410 

Generic  Taxiway  high  speed  area  lights 

0.9 

1  I  0.6  I  0 

Dir 

50 

110 

_ 

_ 

Amber Light 

411 

Amber  high-speed  lights 

0.9 

1  1  0.6  1  0 

Dir 

50 

110 

_ 

_ 

Green Light 

412 

Green  high-speed  lights 

0.9 

0  1  1  1  0 

Dir 

50 

110 

Lead-on Light 

413 

Green  Lead-On  Light  associated  to  a  Stop  Bar 

0.9 

0  1  1  1  0 

Omni 

No-entry Light 

414 

No  entry  zone  lights 

0.9 

1  |0|0 

Omni 

_ 

_ 

_ 

Runway Guard 

415 

Runway  guard  lights 

0.9 

1  1  1  1  1 

Omni 

_ 

_ 

_ 

Stop Bar  Light 

416 

Stop  Bar  lights 

0.9 

0  1  1  1  0 

Dir 

180 

180 

Taxiway Ciearance Light 

417 

Clearance  bar  lights  are  located  at  "hold  short"  positions  on 
taxiways  in  order  to  increase  the  visibility  of  holding  position 

0.9 

1  1  1  1  0 

Omni 

Guard 

418 

Generic  RGL  (Runway  Guard  Light)  is  used  to  enhance  the 
visibility  of  taxiway  holding  positions  on  an  airport 

0.9 

1  1  1  1  1 

Omni 

_ 

_ 

_ 

Type1 Light 

419 

Runway  Guard  Light  Type  1 

0.9 

1  1  1  1  1 

Omni 

_ 

_ 

_ 

_ 

Type2  Light 

420 

Runway  Guard  Light  Type  2 

0.9 

1  1  1  1  1 

Omni 

Type3 Light 

421 

Runway  Guard  Light  Type  3 

0.9 

1  1  1  1  1 

Omni 

Type4 Light 

422 

Runway  Guard  Light  Type  4 

0.9 

1  1  1  1  1 

Omni 

_ 

_ 

_ 

WindJndicator Light 

423 

Wind  indicator  light 

0.9 

1  1  1  1  1 

Omni 

_ 

_ 

_ 

Windsock  Light 

424 

Windsock  light  used  to  illuminate  the  windsock  in  poor 
visibility 

0.9 

1  1  1  1  1 

Omni 

44 

WUNCLASSIFIEDW 


